> I think we've been focusing on different things here. The issue I'm
>> trying to discuss is independent of use of the
>> write-directly-to-the-console method. This discussion is about having
>> std::print() (and std::format()) internally ensure that that format
>> arguments provided by the locale are transcoded to match the encoding of
>> the format string. This happens before anything is written to the console;
>> this is the step where the formatting is done and the intent is to ensure
>> that well-formed text is produced *before* it is transcoded to the native
>> console encoding (whether that be UTF-8, UTF-16, whatever). Transcoding
>> requires well-formed input of course.
>>
>> Does this help to get us on the same page
>>
>
I actually disagree with that.
I don't think there is intent in the current design that the output has to
be text at all. I could use format to create some kind of binary format if
i wanted to, except the _formatting_ string is text because it needs to be
parsed,
So format as specified doesn't put requirements on the arguments
beyond the formatting string and doesn't need to.
What makes print text is that it outputs to the console, at which point
text is assumed.
The transcoding happens after formating, and might as well not

forrmat(a, b, c) -> result
printUtf8ToConsole(result);

The fact that printUtf8 is implemented as printUTF16(toUTF16(result)) is an
implementation detail that should not be observable nor described by the
C++ standard.

And I don't think print should do _anything_ to check for some amount of
validity before printing out something.