But do they really need to also switch the sorting collation?

If you're not doing that, you're not changing locale. Even if previous ILSs half-arsed this, I don't see why it follows that we should, too.

In the English/Spanish case, I guess there's little in the way of real problem, since the English collation rules are basically a strict subset of the Spanish, what with English having virtually no accented characters. But a Danish/Swedish bilingual system would run into much more subtle problems, where the two languages collate accented and compound characters differently.

University of Texas want to switch the language of the user interface between English and Spanish on a per user basis.

But do they really need to also switch the sorting collation? Old library systems only have a single sorting collation per tenant and there was not a need to have more. Users can easily work with lists in sort order of some other language.

Have the SIGs requested that multiple sort collations must be available for a single tenant?

In other words, I think the present issue is necessary but not sufficient.

My take is that in the general case, a tenant will support a set of n locales, all of which get indexed: an obvious example would be a university in Texas that supports both English and Spanish. That being so, I think there is still a need for the queries to indicate which of the tenant's available locales should be used for a given sort.

@Mike Taylor @Julian Ladisch as indicated in RMB-37 the collation locale needs to be indicated at the index construction time for Postgres DBs. Otherwise the search/sort will not employ indices. I think this means that this particular issue is not going to address the problem of locale-specific sorting.