I've been following the discussion and as I can see it's already become rather unproductive*. So I hope my cutting in will not be very much out of place (even if I don't really know what I'm talking about).
Many people here has stated the main reason why a WYSIWYG editor is not feasible is the current wikitext syntax.
What's actually wrong with it?
The main thing I can thing of is the fact one template may include an opening of a table etc. and another one a closing (e.g. {{col-begin}}, {{col-end}}). It makes it impossible to isolate the template from the rest of the article - draw a frame around it, say "this box here is a template".
It could be fixed by forbidding leaving unclosed tags in templates. As a replacement, a kind of foreach loop could be introduced to iterate through an unspecified number of arguments.
Lack of standardisation has also been mentioned. Something else?
I've tried to think how a perfect parser should work. Most of this has been already mentioned. I think it should work in two steps: first tokenise the code and transform it into an intermediate tree structure like *paragraph title: * plain text: "Section 1" content: * plain text: "foo" * bold text: * plain text: "bar" * template name: "Infobox" * argument name: "last name": value: * plain text: "Shakespear" and so on. Then this structure could be transformed into a) HTML for display, b) JSON for the WYSIWYG editor. Thanks for this you wouldn't need to write a whole new JS parser. The editor would get a half-ready product. The JS code would need to be able to: a) transform this structure into HTML, b) modify the structure, c) transform this structure back into wikitext.
But I guess it's more realistic to write a new JS parser than to write a new PHP parser. The former can start as a stub, the latter would need to be fully operational from the beginning.
Stephanie's suggestions are also interesting.
lampak
* (except the WYSIWTF, of course)