I'm dropping the cc: people from this thread; should have done so long ago.

Tom Honermann wrote:
> I don't believe using the locale encoding for the intermediate
> representation
> of the character sequences passed to the streambuf is sound, and I don't
> think
> trying to support this case will lead us anywhere useful.
>
> This already is, and has been for a long time, the status quo as demonstrated.

Let me be more precise.

I don't believe using the locale encoding for the intermediate representation
of the character sequences passed to the streambuf is sound, and I don't think
trying to support this case

** in new, Unicode-aware code **

will lead us anywhere useful.

As I see it, our (and, I hope, SG16's) goals should be

1. Allow writing new Unicode-aware code that reliably produces consistent
results independently of the final output encoding

and

2. Make sure old, non-Unicode-aware, working code stays working.

We are spending a lot of time here on

3. Allow new code to be written that, even though is Unicode-aware
because it uses Unicode character types, wants to stay within the old,
non-Unicode paradigm (that we know cannot work in general.)

And it's not just "allow" - while producing the month name in Shift-JIS
"falls out" of existing LC_TIME support, there is no existing support
of which Unicode translation to the "locale encoding" can fall out.

There's no existing LC_ category for it, there's no facet for it, you have
to introduce new locale machinery in order to support writing new
code that simply shouldn't be written and shouldn't exist.

Note that this applies in the exact same manner to formatting Unicode
literals with "{:L}". You'd still need the new locale machinery.