> You'll always have to use an appropriate font for the task, the encoding won't help you.
In practice in the pre-unicode world fonts were encoding-specific, so the encoding did help. When you viewed a Japanese document it would be in a Japanese encoding and you'd get a Japanese font, when you viewed a Chinese document it would be in a Chinese encoding and you'd get a Chinese font, and when you mixed up your encodings you'd get something that was obviously broken even to someone doesn't speak Chinese or Japanese.
> but those apply across all concerned languages and are not unique to Japanese
They're de facto unique to Japanese; Chinese support "won" in most international contexts, so "CJK" codepoints look fine in Chinese, and those codepoints are rarely used in Korean (mainly in historical documents) so having them rendered "wrong" there matters less in everyday life. Admittedly looking at another article that hit HN today I could believe Bulgaria gets equally shafted (and is probably, sadly, less capable of sustaining a "made in Bulgaria" software ecosystem than Japan is).
> Sure, one can make three codepoints out of these, no big deal. But then 言 occurs in a gazillion of other characters, as in 說這語信 and so on; all of these characters would then need to get codepoints of their own (which btw is exactly what happened with 說 vs 説 (and incidentally 说)). It gets worse when you consider that another one or two components of a given character may also have two or three variants, then you might get 3x2=6 or 3x2x3=18 codepoints for what most people consider a single character. And did I mention we already have around 100'000 codepoints for CJK Ideographs? That number would multiply considerably.
You don't have to add 18 variants, only 3, and that's the worst case. We don't need codepoints for letters that are half-Japanese half-Korean, or every other conceivable variant. But using Unicode shouldn't be a regression from using Shift-JIS.