Proposed resolution:

This wording is relative to N4901.

1. Modify [locale.members] as indicated:

   string name() const;
   

   -5- Returns: The name of *this, if it has one; otherwise, the string "*".

   -?- Remarks: Two locales have identical names only if their facets have identical virtual function semantics.

   -?- Recommended practice: The name of a locale that has a name should be such that setlocale(LC_ALL, name().c_str()) returns a non-null pointer. [Note 1: With such a name locale(name().c_str()) succeeds and does not throw runtime_error. — end note]

[ 2022-03-04; Reflector poll ]

Set priority to 2 after reflector poll.

LWG 2394 removed the only text in the wording that requires that the name of a locale is usable for constructing further locales.

The relevant notes from the wiki appear to make it seem like LWG thought the change was editorial.

Perhaps the resolution was motivated by a different defect than the one that led to the change?

Namely,

explicit locale(const char* std_name);

is said to use "standard C locale names".

There is no LC_MESSAGES in standard C.

Thus, it is a question whether the aforementioned constructor should be able to consume names produced by the C++ implementation.

See also the use of the name of the C++ locale in locale::global() for use with setlocale.

The following would restore the equivalence of locales that have the same name. It also addresses the suitability of the name for use with setlocale and the locale(const char*) constructor as a matter of QoI.