That is not the point; if markdown looks like text A and render like text B looking like text A is not a strength in and of itself.

I would say this would still fall under the realm of readability and of being lightweight (as in a markdown text looks like someone that did not knew markdown could have written)

But it is supposed to render exactly what was written. You write a heading, it gets rendered as a heading. You write the number 2, it ought to be rendered as the number 2.

Most markdown parsers don’t work properly you begin with. The issue isn’t the text written. It’s poor parsers.

> Most markdown parsers don’t work properly you begin with. The issue isn’t the text written. It’s poor parsers.

I think this isn't exactly fair, in that it seems to mislocate the problem——Markdown itself is so underspecified (I think Gruber never really expected it to take off the way it did) that the meaning of 'Markdown' can vary wildly from place to place, as a result of which there's no simple, universal test suite, and it's hard to tell on what sort of edge (or not-so-edge) cases your homerolled parser will trip until you actually deploy it (at which point people have come to rely so much on its quirks that it's difficult to fix it).

Indeed, Gruber has resisted efforts to more thoroughly specify parts of the syntax (resolving ambiguities in parsing), saying that the original form works for his needs. This "power vacuum" has led to things like CommonMark (https://commonmark.org).