The authors argument that Markdown should be discarded because there are several competing implementations isn't valid.
For many years (even now), we have several competing implementations of HTML, yet the HTML document is the dominant presentational document format (and UI layout language). It hasn't done anything to hurt adoption.
The fact that Markdown does have a common subset of features, and that Markdown is widely interoperable with a vast amount of products is why it wins. As far as I can tell Org-Mode markup is used within Emacs and really nowhere else.
The argument isn't that Markdown is bad because there are competing implementations. The argument is that Markdown is bad because there is no standard for those implementations to adhere to, so they end up being wildly incompatible. With HTML, there will be browser differences, but there's a pretty well-defined standard which browsers try to adhere to; there will be bugs, but at least you can know you're writing standards-compliant HTML, and then work around particular browser engines as necessary.
You say Markdown has a common set of features, but what is that common set? There's no standard, and I find myself surprisingly frequently struggle with figuring out what's the correct way in a particular markdown engine to do what I need to do.
An example is that in Reddit's markdown; this text:
```
if (true) {
console.log("hi");
}
```
Markdown engines are also wildly inconsistent about when they treat something as a link, and whether they require a blank line between a paragraph and code blocks or lists.
They seem to mostly agree about how explicit links and bold and emphasis and headings work though, so if that's your consistent common set of features, I suppose you're right.
> The argument is that Markdown is bad because there is no standard for those implementations to adhere to, so they end up being wildly incompatible.
This argument is valid, but…
> An example is that in Reddit's markdown; this text: [snipped] will all end up as inline code, with all the newlines and extra whitespace stripped out.
This does not validate the argument. Implementations defer to John Gruber’s Markdown Syntax Documentation.[1] It is insufficient to be used as a standard (hence your argument being valid), but does (in some cases) provide a common subset of features compatible everywhere. The “fenced” code block is not included in Gruber’s original Markdown, but became so popular due to GitHub that people come to expect it. It is still not part of “Standard Markdown” though.
Furthermore, GFM* has fast become a defacto standard for newer implementations—still a bit of incompatibility, but improving.
* GFM = Github Flavoured Markdown, even if Gitlab have very cheekily taken on the same initialism for their (in fairness, highly compatible) flavour.
Has anyone found a good GFM to HTML converter that does not call out to a SaaS service (often GitHub)? I keep ending up in use cases where I need to do this conversion or do a live preview without having the data leave the box. When I was looking around previously I found out that under the hood they were using the GitHub API to actually do the preview.