I wanted to thank you for mentioning NSM. I hadn't heard of it before and it's quite exciting and interesting research—seems like a fantastic jumping-off point for building a small language!
See, you're overcomplicated things so much with your precision, you're really missing the point. You can communicate by giving flowers, but you won't be able to convey this conversation with them. Nevertheless, on the occasions when you might use flowers to say something to someone, if you instead try to use a lengthy thread on Hacker News, your precision level will be very high but you will completely miss the point.
You should consider taking up Toki Pona as a hobby. You should try and take meeting notes in Toki Pona at work. You'll be surprised at what you find yourself thinking—even though you won't be able to use the notes in the way you would your normal notes.
What's funny about that is, it would turn the thread into "I like Good Talk," "I think this: Good Talk is yucky!" which exposes as much as it conceals. :)
The value of Toki Pona is in making fewer distinctions rather than more. You really couldn't have the conversation we're having right now in Toki Pona, but that's not what it's made for. Criticizing it in these terms is a bit like criticizing Perl because it's hard to read over the phone.
You can hardly blame links for that. There was no widespread hypertext format before HTML for conventional renderings to appear in. Most of the rest of Markdown has analogues in earlier plain text formats and is fairly visually suggestive.
Common Lisp managed to unite several divergent implementations of Lisp (MacLisp, InterLisp, Lisp Machine Lisp, etc.) under a single common specification. This was possible because the Common Lisp standard was not created by some third-party out of dissatisfaction with the other guy's stuff but by significant representatives from all the big camps. The desire was for better interoperability, not imposing ideals on the competition.
I think this effort, if Gruber supports it, is likely to succeed simply by incorporating most of the community. In fact, it could be even easier, because one of the principle motivators for the divergent implementations of Markdown is simply to create concrete specs around a concrete grammar. This doesn't mean there won't be divergences (Scheme, Clojure, OpenLisp, etc.) it just means that those divergences will be principled ("we reject the size", "we desire modern FP techniques") rather than accidental ("we used this regex instead of that to tokenize emphasized text").
You're missing the point, and you're missing it hard. Look at CSV. Do you want a repeat of that fiasco? That's a format with literally one feature, and yet in the wild it comes in so many varieties you must guess and configure with every CSV parser. We're in a unique situation here in that the progenitor of the format is alive and can appoint a successor to avoid that whole problem.
"But one of the goals of Markdown is to provided easy-to-use markup for text." This is in no way contradictory to the aim. The idea here is to standardize Markdown, not to replace it with XML.
"I think that people will get on board if it provides a clear advantage over Markdown as it exists as well as other markup formats." The clear advantage is that the parser won't have to guess what you meant and thus get it wrong. The clear advantage is that when you enter copy text from Github and paste it in a Reddit comment box it will come out looking the same. The clear advantage is that in ten years there is a flag for "Accept Standard Markdown only/Accept my weird extensions" to establish a baseline. The clear advantage is that your files won't have an expiration date. The clear advantage is that you won't spend months closing tickets and replying to emails entitled "Why is my formatting all fucked up?"
"Only geeks will complain about whether the successor of Markdown is deployed." Yes, and only geeks care about standards, because only geeks understand the immense difficulty that is supporting a family of mutually incompatible formats and protocols and therefore only geeks understand what standards actually do for them. Users may not care, but when shit breaks they have this unpleasant habit of blaming us and our work, and I find it frankly insane that any reasonable programmer could resist an effort to make their life and the lives of their comrades easier, practically for free.
"If enough people get behind this, it won't matter that Rockdown is a peer to Markdown." Have you ever worked with scientists? There is code in my codebase written in Fortran 77—and that code was written two years ago. Not everybody is interested in upgrading on your schedule. In fact, in many places, obeying the standard is the standard practice, and there is absolutely no interest in performing time-consuming comparisons to figure out independently what is technically superior to what or even what the options are. Standards are intrinsically valuable to these organizations, and you will inevitably find yourself tasked with dealing with them. You're essentially saying "Why declare a standard when we can just rely on word of mouth and let people figure it out?"
I hate to impugn a fellow HNer, but I really can't abide this sloppy, half-assed, incomplete thought. This initiative is obviously the right thing to do, or at least try to do. If you disagree, I curse and damn you to ten years of supporting incompatible highly-similar formats, after which I am certain you will see the utter pointlessness of it and the ease with which it can be averted and agree with me.
It's consensus-building. If the creator of Markdown says the successor technology is Rockdown, everybody who deploys something on Markdown will get hate mail: "why aren't you using Rockdown? Gruber says it's the future." If that doesn't happen, Rockdown is just a peer to Markdown—an improved, specified peer but not anointed. It leaves the window open for people to say, "well, I like flavor-X Markdown better than Rockdown, so that's what I use."