> as we know it today

An important nuance you seem to be missing is that SUSv3 is equivalent to "IEEE Std 1003.1-2001" (that is, POSIX 2001).

In practice, I've had to work around more POSIX compatibility issues in macOS than in all other actively developed (Free) Unix-likes, combined.

"ou" is fine too, actually. See the proposal p. 14 (=16 in the PDF): https://www.bunka.go.jp/seisaku/bunkashingikai/sokai/pdf/942...

(To differentiate between the case where it's actually two vowels, you have to put an apostrophe inbetween; their example is 小唄 -> ko'uta.)

The "other standard" in this case being IBM-944. (At least looking at https://www.unicode.org/versions/Unicode1.0.0/ch06.pdf p. 574 (=110 in the PDF) I only see a mapping from U+212A to that one.)

The ICU mappings files have entries for U212A in the following files:

    gb18030.ucm
    ibm-1364_P110-2007.ucm
    ibm-1390_P110-2003.ucm
    ibm-1399_P110-2003.ucm
    ibm-16684_P110-2003.ucm
    ibm-933_P110-1995.ucm
    ibm-949_P110-1999.ucm
    ibm-949_P11A-1999.ucm

w3m doesn't support chafa for inline image display.

(You can set a custom w3mimgdisplay command, but it has to speak the same protocol as w3mimgdisplay. If you're feeling adventurous, you can try modifying https://github.com/uobikiemukot/sdump/tree/master/yaimg-sixe....)

> which aren't just free to use, but explicitly use the modern SIL Open Font License.

Unifont is also dual-licensed under GPLv2/SIL OFL.

> It would also be nice to have something like `default-styles: none` so I don't have to deal with browsers having differing defaults.

This already exists:

    *, ::before, ::after { all: unset }

The greatest mistake IMO is the way float state leaks out of blocks, as this is both extremely unintuitive and undesirable for performance reasons.[1] Floats should've been restricted to inline formatting contexts, with all in-flow blocks behaving as if they had `clear: both' set.

I also don't understand why they never specced the (much simpler) `text-align: -moz-left/-moz-right/-moz-center' which already had precedent in HTML with `<div align=left/right/center>'. It's the saddest part of the "center a div" saga, all the W3C had to do to fix it is to assign a standard keyword to a feature that everybody already implemented, but to this day it still hasn't happened.[2]

[1]: https://pcwalton.github.io/_posts/2014-02-25-revamped-parall...

[2]: After many long decades, they did finally specify block-level `justify-items'. Two problems: a) it's backwards-incompatible with text-align, b) it still doesn't work in Gecko.

I actually wonder if transpiling calc/min/max/etc. expressions to JS is a viable path to implementation, considering that you already need a fast interpreter for these.

> just new ones that no automation depends on

Except for automations that happen to create new repositories.

> Rendering Markdown is relatively simple

Markdown is a superset of HTML, so your assertion cannot be true. But even an HTML-less subset is very hard to parse efficiently (or, at all) because of the various grammatical ambiguities. And then there's the various competing definitions...

> And then there's the various competing definitions...

Someone always bring this up whenever a permutation of this thread comes up, but I don't see the problem. You choose a definition and make that the spec. Even Hacker News only supports a very limited subset of Markdown.