Ok only mind that those are code points, the actual encoding to UTF-8 seems to be done elsewhere
I'd suggest against the use of wchar to store unicode characters, it was really designed for UCS-2 encoded text, when Unicode was smaller and 2B were sufficient.
Now that Unicode counts 143'859 chars, it's used to store UTF-16 text. That means that a character can take up to 2 wchar. If I remember correctly, wchar I/O functions are also considerably more complex (and slower), as they re-encode the text to match the current locale, but this in Linux I don't know about Windows.
In my library, for example, I store them in uint32 variables, already UTF-8 encoded, but that's an edge case because I move them around like pixels, so that approach might be a waste of memory in other contexts. In
your situation, I think a fixed-size approach is still the best way to go, something like char[4], or even uint32, but you have to be careful with endianness.
which happens to be similar to the external-file-with-default-provided method of dealing with the planned customizable glyph mirroring behavior
Yeah, I've seen related requests here and there in the forum, if you think about it, you could implement some character-based logic to flip/mirror layers, and the mapping would make sure that the most appropriate tile is chosen. But going beyond that looks non trivial. That would require some syntax to define unique pairs, and everything should still be optional. Json may prove to be more versatile (maybe for the settings too, just sayin') :)