> No, UAX #11 does not define the width of characters.

It's literally there in the doc

> It’s called “East Asian Width” for a reason. As the note in the Scope section begins:

Yes. I didn't claim it defines terminal cell widths. There's a reason you need a library to translate that into cell widths. What I said was you don't need to be pratt about with printing because Unicode does define widths and properly libraries pin against that (like POSIX does).

> Terminal emulators have piggy-backed onto it because it’s fairly close to what they want and definitely better than nothing,

That's a very convoluted way of agreeing with me :)

> but if they limit themselves to this definition, they do a bad job.

A large part of the problem here is you're introducing scope creep.

> To see the most extreme example, look through Google Fonts for U+FDFD <https://fonts.google.com/?preview.text=%EF%B7%BD> and see the radical differences in aspect ratio (and size!).

You're shifting goal posts again because you're no longer talking about fixed width typefaces. Terminals have to make some concessions for turning scripts (of any language) into fixed width. If that's an issue then you shouldn't be using the terminal to begin with. There are better standards for that, such as the web.

In short, nobody is going to disagree with you that Unicode is hard and full of edge cases. But the vast majority of the stuff you describe are either already solved, already have standards, or are already out of scope for terminals.