And how exactly would one even put this genie back in the lamp?
In seriousness: Most Markdowns are 1) fairly similar and 2) sufficient for the vast majority of documents. If the goal is a stable, mature, and complete markup language, I'd be inclined to give LaTeX top billing. Markdown can of course generate LaTeX.
LaTeX can, whether through the old model of dvi, or modern tools such as xlatex and pandoc, directly produce numerous document formats or "endpoints" as I consider them, including HTML, ePub, plain ASCII (or UTF-8) text, or paginated formats including ps, PDF, and djvu. LaTeX is not itself fundamentally print-oriented. The fact that it can and does produce excellent print-formatted output is a feature, not a bug.
What it is, and pointedly in ways that HTML lacks, is capable of intrinsically handling document-centric (not merely "print") elements including footnotes, endnotes, and formulae, all of which still require kludges after over a quarter century on the Web.
Markdown itself does not address several typographic or document conventions, including formulae, but also odd omissions such as underline and coloured text. Whether those get shimmed into Markdown, or an alternate (light- or heavy-weight) markup language is adopted, isn't clear, but those are very annoying lapses.
For the vast majority of documents, this does not matter. Most online content, say news media, use little more than paragraph, italic, and anchor elements. Even bold and list are rarely used. Authoring in Markdown should be almost wholly sufficient, but it's (La)TeX which has sufficient richness of expression to serve as the common underlying document format language.
Late edit: It also occurs that another principle angle of attack on HTMK alternatives, raised elsewhere in this thread, is that these cannot guarantee pixel-perfect presentation. That results in rather a "damned if you do, damned if you don't" situation: propopsed markup alternatives either cannot guarantee layout or over-guarantee layout. These objections rather want for consistency.
Counter argument: then why do conditional comments behave differently in each browser engine?
I am not talking about trident, but about CSS hacks for presto, gecko, webkit and blink as well.
If every browser would render as specified, we wouldn't have that outcome.
As developers test on webkit/blink primarily, chances are very likely things will not behave the same in other engines, and if blink violates the spec then everybody will also have to violate the spec.
The internet is built on such bad standards that you cannot even rely on HTTP to work correctly. 206 partial content headers behave differently among all web servers and proxies, and even nginx violates the spec there when it comes to multiple ranges, let alone chunked transfer encoding support.
> Counter argument: then why do conditional comments behave differently in each browser engine?
They don't. IE5-9 sees conditional comments specially, others don't.
> I am not talking about trident, but about CSS hacks for presto, gecko, webkit and blink as well.
CSS isn't HTML5, and those hacks aren't conditional comments, and don't rely on parsing differences.
> If every browser would render as specified
The claim was about parsing HTML5 and generating a DOM, not rendering.
A common theme in all these "reinvent the web/browser" discussion is going back to the web as a hyperlinked document library and not an application platform, in which case pixel-perfect rendering is neither necesary nor even a goal.
For example, implementing comment parsing per the letter of the HTML4 spec is extremely not-web-compatible
HTML5 parsing is completely specified and definitely compatible, even the error cases. Any stream of bytes will turn into a DOM. (Philosophical question: are they even errors anymore, if all implementations will produce the same output?) Perhaps that would be a good starting point.