(Ground rule of this Topic: No Politics!)
1: So, the problem with 1. (and it’s “the problem” that Jeff identifies in his anti-wysiwyg essay) is that in a strict markup+preview model, you can’t accurately translate the cursor position from the preview to the markup. It becomes very easy to make broken/interleaved tag pairs, especially with markdown’s identical opening and closing tags.
The “best option” identified from the previous thread, ProseMirror gets around “the problem” by using an intermediary format that has none of markdown’s confusions. It’s rigidly and flat, and works as you’d expect a rich text editor to work. Try as I could, I couldn’t make it break by bolding, italiccing, listing and de-listing arbitrary chunks of text.
It has nice ToCommonMark and FromCommonMark functions but they don’t support all the features of Discourse’s editor (most importantly, HTML) so as we were warned, it would only be “flawless” on a blank installation.
3: I guess my no.1 concern with such a scheme would be: What happens when/if the plugin is removed? What happens when you try to edit a post that is actually a big blob of html? What happens when you edit a pre-existing markdown post with the new plugin?
I admire this effort, and might even contribute financially if it comes to it (and it appears doable). But I’m not optimisitc. I think Sam’s warnings are real (and he should know).
The problem has so many edge cases, there’s barely anything left in the core 
I think a “first shot” should be an implementation of ProseMirror, that sits on top of the existing editor, reading and writing to the editing area with FromCommonMark and ToCommonMark - It’ll be clumsy and I’m sure performance will take a hit, but it’s probably a realisitically achievable goal.
I have absolutely zero applicable skills with which to attempt any of this 