Postgres – Check ICU Libraries Availability for Postgres 10+

--disable-strong-random is a PostgreSQL configuration option available in the ./configure script in the source code. You could check to see if your version of PostgreSQL and the associated contrib modules were built with it by using pg_config --configure and looking to see if that particular flag was passed in as part of the config process. Though as it says in the thread that was linked, no reasonable production platform would use that flag, so odds are that you've got a cryptographically random build.

First let's note that at the time of this answer, PostgreSQL 10 in still in beta stage. Some issues about the ICU integration and how it's documented are still under discussion, and there might be changes before a GA release.

➠ How does one specify the ENCODING, LC_COLLATE, and LC_TYPE to use the new ICU collations?

It's not possible currently (and probably not documented well enough, or not clear enough in the error message: when it says invalid locale name, it means from the set of locales provided by libc).
This is discussed in this thread on the developers mailing list: Can ICU be used for a database's default sort order?

➠ What ICU collation names you would suggest for English-oriented databases? For Western European multi-lingual databases?

It mostly matters if you have specific sort requirements. In this other thread of the mailing-list:
What users can do with custom ICU collations in Postgres 10
some concrete examples are given of ICU collations behaving specially compared to what libc can do.

When not having specific requirements, I think most applications won't care whether they use an ICU collation or a libc en_US collation, except for portability. One of the big points of ICU is to get exactly the same ordering across all operating systems for a given locale, which is really not the case of libc. I guess that the pre-created en-x-icu would be fine for general English, and for West-european languages, I'm not sure why any collation would be better than und-x-icu.

As a side-note, it's not a good idea to use any other collation than C when you don't really care about the sort rules, because C as a collation will outperform any language-aware collation. And C is portable across operating systems.

➠ What are the possible ICU collation names?

Although initdb populates pg_collation with a list of pre-defined collations, a complete list would be subject to combinatorial explosion, as ICU collation names are formed by assembling tags, as listed here: http://unicode.org/reports/tr35/tr35-collation.html#Setting_Options

Currently the doc does not mention explicitly that you can do:

CREATE COLLATION mycoll (locale='my-set-of-tags', provider='icu');

but I think work is happening right now to improve that in the doc.

Another issue that might be worth pointing out is that there are multiple ICU major versions out there, and the list of pre-defined collations that initdb instantiates differs significantly between these versions, especially ICU pre-53 versus post-53. This has been put in evidence in another discussion: Crash report for some ICU-52 (debian8) COLLATE and work_mem values

EDIT: in the next beta or RC, the list of ICU collations created by initdb will change thoroughly , as mentioned in this discussion. The list will made by iterating on ICU locales rather than collations, and as a result the question "What are the possible ICU collation names?" will have to be reconsidered with the new values.