Another reason for using almost monospace: international languages. Many indic languages simply don't have good monospace fonts. It's not easy to design. They stick out in code, as a result.
But I've always wondered if allowing three or four different widths would help. We could still align text if (narrow) spaces were the smallest unit, and other widths were repeated multiples of that.
Same goes for East Asian languages which are monospaced, but square. If you mix English (or code) with Chinese/Japanese/Korean, you get a mixed-width mess.
It’s well-defined, at least in the terminal: the east-asian characters are simply double the normal width. There’s a Unicode property to decide which is which: https://www.unicode.org/reports/tr11-2/
They still line up (when rendered with correct double-width), the east-asian characters just take up two “slots”, as if they were two normal characters. I don’t know if you see a problem with that, or if you’re talking about renderers and/or applications that don’t correctly handle this double-width logic.
My point is that if handled correctly, e.g. in terminals, there is no problem with that, as long as the application is double-width aware. For example I use Mutt as a mail reader in a terminal, with Vim as an editor, and mixed latin and east-asian characters work fine with them and line up on the terminal grid.
I don't think I've ever seen a double-width font outside of an actual terminal emulator though. It's really frustrating that the fonts used by all IDE's and graphical emacs/gvim/vcode seems have this mixed script spacing issue.
But I've always wondered if allowing three or four different widths would help. We could still align text if (narrow) spaces were the smallest unit, and other widths were repeated multiples of that.
This makes me think it's doable.