Sorry, but the third one I disagree. I think it's putting the cart ahead of
the oxen.
We don't *need* the char8_t library APIs you're talking about. We've had those
APIs with char for 50 years and all the existing text-processing libraries for
the arbitrarily-encoded char already do exist that fill in this niche. We must
support arbitrarily-encoded char anyway, so there's little incremental value
in having an identical API that supplies the encoding by the type's name
instead of an extra parameter somewhere.
If we had had those APIs already, adding the char8_t overloads would have been quite trivial. Just reinterpret_cast to char in the println wrapper that accepts char8_t or something, and you're good to go. In reality, we don't have those APIs. We have some APIs that work with char and then you need to go through OS-specific ways to manipulate some global locale to make things work. There's no way to simply print a bunch of UTF-8 code units, which is what we actually want.
We don't even have a cross-platform way to bundle char* with some enum which specifies the encoding of the string. There's not a single function in the C standard library that would let you bundle char* with encoding.
Given the total absence of any sound and portable functionality, given that we're basically starting from scratch (not counting OS-specific functionality), we may as well design it properly, with a type that is intended purely for UTF-8 text, as compared to char, which is a bit of an integer, a bit of a byte type, and a bit of a text type with unspecified encoding, but ... maybe UTF-8. Why can't we have the sound design that virtually every language after C++ managed to get right?
Plus, all those APIs are currently inaccessible if you started your text's
lifetime with char8_t. So I fear char8_t is locked into a chicken-and-the-egg
problem: you can't use the existing char-based APIs with it, which means
people won't use char8_t, which means there won't be new char8_t-based APIs...
Not every part of the problem is chicken-and-egg. Unicode transcoding, character property tests, std::format, std::from_chars, and many other utilities don't even require any OS-specific functionality.
And if we "already have" those APIs for UTF-8, then just use them, right? You can reinterpret_cast char8_t* to char* just fine. You're making it sound like we have the chicken already then.