If you want to render Markdown in a way other than plain text, you need formal rules of parsing it. No matter how informal you want Markdown to be, if you want e.g. a nicely rendered Readme on Githiub, you have to follow the formal rules.

One downside of markdown being so flexible is that it's hard to remember if a given dialect implements a certain feature, or how it will handle a certain corner case

I think I see the appeal of specifying a robust subset of markdown, something that you can trust will probably be parsed the same way for as many dialects as possible.

I totally agree with this. It's quite annoying you never quite know what dialect some website is using, they never mention, because it seems very few of these dialects have names.

What also annoys me is that they didn't base it off Wiki formatting. It would've been great if it had at least some compatibility for basic stuff like headings and links.

I have my agenda https://news.ycombinator.com/item?id=25961188

lists are one of markdown's weak points though with numbered lists completely ignoring the numbers

Thats optimized for never having to renumber yoir lists as you edit your document.

I would hate to have to change 30 numbers because i want to move an item from last to first.

Optimizing for readers definitely excludes lists like:

    2. 
    3. 
    5. 
    6. 
    1.

Tbf it’d be trivial to have a button/flag to fix it in the source, and a warning to notify the user. It’d might be debatable to do so automatically, but on demand there’s no issue (like words table of content update/warning).

But the current definition of “its always sequential, that’s it” means you could do it automatically without changing meaning. Whereas do-as-I-say is stuck with being unsafe, always

This is the same as HTML's <ol> though...