I haven't fully understood your suggestion (in the other question). However it does appear you have misinterpreted the use case of the POSIX locale.
Your suggestion seems to be that the locale is not very user friendly. And that it should be adjusted to make it so. However user friendly isn't the point of the posix local, that's the job of other locales with other rules.
The job of the posix local is to be predictable. Indeed it also benefits from being simple. Once you start including other languages into a standard it is very difficult to stop, and the result is a standard that needs a lot of maintenance and is hard to implement.
There is no way that I, as a developer know every rule about every language, how to sort them in "alphabetical" order and indeed know which are upper or lower case. The rules for non-english languages can be very complex indeed. So if you adjust the Posix local to include the rules for every other language, you would make it's behaviour very unpredictable indeed.
Changes to the posix locale could indeed be crippeling to software where older systems did not match the behaviour of newer systems. (See anecdote below)
Anecdote
One of the most obscure and difficult to diagnose bugs I've ever seen was in an ETL tool "randomly" dropping rows. After painstaking analysis, it transpired that the software worked fine, but only if run with LC_COLLATE=C. This was because, when matching records, it relied on the sort order from a database matching its own internal sort order. The developers had simply never noticed that in some locales numbers would sort text alphabetically "0, -1, 1, -2, 2" instead of "-1, -2, 1, 2".
Quite aside from user interaction, what this shows is a genuine need for systems to behave in a predictable way that can be common to all systems.