Advocating a new global constructed language to accomodate C's shortcomings seems like the wrong direction to be thinking.
Less a global constructed language, more a "better" encoding. Base64 works really well for arbitrary binary-in-text encoding, for instance.
Unicode is that better encoding. The "small and efficient per locale encoding" that you proposed was the status quo, and was an endless source of mojibake. There is a reason we moved away from that.
I think there is a misunderstanding, which I tried to address but evidentally failed.
UTF-8 is fine for a display encoding. However, not every string encoding need be a display encoding, which the parent post seems to not be considering.
You could also have multiple display encodings, if it makes sense to (a tool only intended for use in a certain part of the world for instance), however that is not what I mean.
I mean if your viewpoint is to handle heavy UIs then yes maybe C is not your go-to language. However, there are other solutions to the character space problem besides UTF-8. Rather than complaining that your screwdriver can't bang nails, perhaps try using a screw?
No, you won't be able to support a language like chinese within a 256 bit charset, but perhaps it's not important to in all situations. The strength of ascii is that its small, simple. If that's too anglo-centric for you, maybe there's a better symbolic tiny charset that is more applicable. I'd support something like https://lojban.io/ becoming more prevalent, but there could be advantages to having a simple(r) symbolic transmission language not burdened with anglo-centric concepts.