I wouldn't go that far, despite having made an early decision to support only UTF-8 in my own software. UCS-2 is in fact broken, but UTF-16 is a valid encoding

I wouldn't go that far, despite having made an early decision to support only UTF-8 in my own software. UCS-2 is in fact broken, but UTF-16 is a valid encoding of Unicode, which can be implemented correctly. So is UTF-32, although I can't imagine why anyone would want to use that one. I can imagine why someone would want to use UTF-16, though: interoperability with Windows, where it's the native encoding. It isn't "wrong, period" to do Unicode in a way which is more convenient for the platform. There is, of course, a ton of work to really implement Unicode correctly, and UTF-16 and UTF-32 can make it tempting to do the wrong thing, instead of biting the bullet and implementing all of the many ways in which codepoints coalesce into grapheme clusters, and making sure all functions for working with strings can recognize the distinction. But it certainly can be done in any of the full encodings.