[Daemon404]

What has been the rationale or hinderance for not adding locale-independent versions of various stdlib functions?

Practically every second C codebase on earth has their own implementations of these at some point, and it remains a huge problem for e.g. writers of libraries, where you don't know how/where your library will be used.

[msebor]

First, there needs to be a proposal for adding a feature (I'm not aware of one having been submitted recently). Second, any non-trivial proposed feature needs to have some existing user experience behind it. For libraries that typically means implementations shipping with operating systems or compilers (but successful third party libraries might also be considered). Finally, it also needs to appeal to people on the committee; that can be quite challenging as well. Many proposals that meet the first two criteria die because they simply don't get enough support within the committee.

[Daemon404]

Sounds mostly like the issue is nobody has bothered to submit a proposal for it then? (There is so much in-the-wild experience and code dealing with this issue, I cannot imagine the second point being problematic.)

On the third point, I have trouble thinking of any technical objections to such proposal.

[rwmj]

To clarify, do you mean functions like c_isalpha (part of Gnulib) which is like isalpha but only matches 7 bit ASCII characters?

[Daemon404]

An easy (and problematic) example is decimal separators (radix characters) being parsed or written differently based on locale.