This is entirely undesirable. First of all, char16_t and char32_t are kinda useless as there&#x27;s no standard interfaces using them, and there&#x27;s no conversion functions to and from wchar_t.<p>Secondly, no, you&#x27;re asking for a massive addition of 2 new versions for every interface that mentions wchar_t. That&#x27;s a huge addition to standard libraries. That&#x27;s error prone and bloats things up. Then additionally you&#x27;re asking for a rewrite of all software using wchar_t. And only until everything is transitioned, which isn&#x27;t going to happen, the standard libraries will be much larger.<p>The solution is rather to embrace wchar_t and fix it. All sensible and modern platforms, which is a premise of this article on modern POSIX functions, have a 32-bit wchar_t type. That&#x27;s excellent. It&#x27;s only Windows, which due to historical short-sightedness that have 16-bit wchar_t. But writing portable C for native Windows is a losing game, the winning move is not to play. (Do see midipix which is upcoming and will provide a new POSIX environment for Windows with musl and 32-bit wchar_t). In fact, 16-bit wchar_t violates the C standard. That moment you give up broken platforms with 16-bit wchar_t, wchar_t works as intended, and this is a non-problem. Embracing char16_t and char32_t is a worse problem and isn&#x27;t solving anything.