UPDATE – this answer, though it seemed to make sense to me and others, turns out to be largely wrong (and sufficiently wrong regarding the intent, as to be effectively just plain wrong). Since (as pointed out in a comment by AProgrammer) it’s not permitted to use UCS outside of string constants when the same character could be represented normally in the base character set. So, no using it to escape keywords, as in my example; and no using it to make ‘identifiers’ like 23skiddo by escaping the 2. It could still be used to make names compatible with external languages, I guess, but only, it seems, when those names start with either a letter or an extended character, and contain only letters, digits, underline, and extended characters — which seems much too restrictive to properly support that intent. So it must be that the main intent is (as in AProgrammer’s answer) to allow these extra characters in identifiers, and to enable source editors where these characters are displayed graphically, while still allowing the source file to be in plain ASCII.

C++ programs may call functions written in other languages. It is good strategy on the part of the standardization committee to ensure that C++ will be interoperable with other languages which may allow non-alphanumerics or unicode characters in function names, even if such languages do not yet exist. The standard doesn’t need to specify how this will work at the linker level, etc; but it’s good to have a specified mechanism in place to allow it.

You don’t need to look into the future to see a use for this. Suppose I have an old C library with a function in it called catch (or protected, or mutable)… and I want to call it from C++. And for whatever reason I can’t or don’t want to modify the C code (By the way, I have more than once had to deal with old C code that used a function name that had become a C++ keyword…)

With UC names I can write this in a header, and then just call ‘catch_func()’:

extern "C" {
       int catcu0068( int a, int b );  // C 'catch()' function
}
inline int catch_func( int a, int b ) { return catcu0068(a,b); }

Sure it’s ugly, but it doesn’t matter since it’s only in one place in the header. The same approach could be used to make stubs to call functions in other languages, and works even if the names are C++ keywords or unicode, or have spaces, . or other punctuation embedded in them

Various other languages have devices allowing the creation of identifiers that don’t follow the general pattern; for instance in Verilog, abcd is an identifier equivalent to abcd, but while and 23skidoo and 44.e2 are identifiers too, which need the backslash prefix to be seen as such. Due to the manner in which Verilog is used, it’s important to allow any names at all, where they relate to external interfaces.

It allows a system allowing unicode characters in identifier to export the source in a format compilable on any standard conforming compilers. I.E. it is a way to encode unicode over the basic character set (more or less like quoted-printable is used for email, systems who knows better are able to do a better job, other systems are still working).

Someone may want to create an identifier using a foreign language character that is not enterable on the keyboard or input device. Alternatively, the identifier may contain a character that is not printable using the font or output capabilities of the device but the IDE wants to show an accurate representation.

C++ requires that actual extended characters appearing literally in source behave identically with Universal Character Names. Allowing Universal Character Names in identifiers permits programmers to use extended characters in identifiers.