If you want to be cheeky you can argue that "hidden assumptions going from a 16 bit wide character set to a 20 bit wide character set" is still correct, because those hidden assumptions are part of UTF-16, and UTF-16 uses exactly 20 bits to express the astral planes, encoding them in a different way from the BMP.
Not sure how this'll come through on ycombinator, so it's also on a pastebin for 24 hours: https://paste.debian.net/311370/
~$ cd src
~/src$ mkdir œuvre
~/src$ cd œuvre
~/src/œuvre$ printf '#include <stdio.h>\nint main() {puts("hello œuvre");}\n' > œuvre.c
~/src/œuvre$ g++ œuvre.c -o œuvre
~/src/œuvre$ ./œuvre
hello œuvre
$ g++ --version | head -n 1
g++ (Gentoo Hardened 4.9.3 p1.1, pie-0.6.2) 4.9.3
$ uname -r -m
4.1.6-hardened i686
$ echo $LANG
en_US.UTF-8
$ bash --version | head -n 1
GNU bash, version 4.3.42(1)-release (i686-pc-linux-gnu)Naturally there's still the issue of properly identifying double-wide characters. But as long as you can correctly identify them (and for the ambiguous characters it generally treats them all the same, either as narrow or as wide depending on the software in question), you can simply render them with 2 cells instead of 1, and everything remains lined up.
But the article here was showing monospaced text in a web browser, and a web browser doesn't do any of this (nor a rich text editor). Font fallback usually attempts to maintain properties like monospacing, but the fallback font may still have different metrics, meaning it won't line up with the monospaced text from the source font (and depending on the fonts available, if you have no monospaced font with asian glyphs it would have to fall back to a non-monospaced font).
I suspect what's going on with the locale stuff here is simply that the locale affects the fallback list, and it ends up picking a different font that happens to have the right metrics to line up. But I can't say for certain that this is the explanation.
I somehow suspect those aren't the same people.