2. Section 6.1.2 "Identifiers", p 34 par 6 (Implementation Limits): Change the second sentence from: "The implementation may further restrict the significance of an external name (an identifier that has external linkage) to 31 characters." to: "The implementation may further restrict the significance of an external name (an identifier that has external linkage) to 31 characters and restrict the characters used in such a name to members of the basic character set."
3. Annex K "Implementation-defined behavior", p549 K.3.3 "Identifiers":
Add a third bullet:
"-- Whether extended characters are permitted in an identifier with external linkage (6.1.2)."
A kludge that could be used to address the problem would be to shorten such names using a checksum. This is the approach used to accommodate C++ mangled names on OpenVMS. But C++ is not C. C++ external names have traditionally involved algorithmic mapping of the identifier spelling used in the source code to obtain the spelling used in object code, and so a name-shortening algorithm is not really a new burden for C++ programmers. But it would be for C programmers. Perhaps more importantly, what the users of extended characters really want is for them to be fully supported everywhere. There is no reason why the linkers, loaders, and other object code tools could not directly support extended character identifiers, and do so much more efficiently and with better system integration (i.e. for display) than the kludge-upon-kludge approach - except for time. It takes substantially more time to work this kind of change throughout all the tools and infrastructure of a mature operating system than it does to do it within a limited set such as a compiler and debugger. If C9X requires support for this not-fully-mature feature within external names, vendors wishing to support the standard as soon as possible will be forced to use a kludge like this. They will then have to carry the kludge around forever (binary compatibility) even after they have built fully integrated support into the rest of the system.
The C language has survived quite well even with its 6-character monocase limit. C9X has made a huge improvement there by requiring 31-character case-distinct. Let's let the kinks get worked out of extended-character identifiers within the confines of the compiler and debugger without imposing such a sudden huge capacity leap on other tools that only a horrible kludge can make it work in reasonable market time. Let customers who are not satisifed with the limitation demand support from their vendors, rather than requiring it in the standard on day one.