There is the obvious issue with backwards
compatibility there,
although that can be overcome with work. The other major issue is that
no WYSIWYG system is likely to be as powerful as wikitext, or as quick
and easy to use (for experienced users). WYSIWYG is certainly much
easier for new users, but once you are familiar with wikitext, it is
generally better.
Actually, I don't think these are even the worst problem. The worst problem is
that the wysiwyg editor would have to cover the full range of what wikitext can
do now - and it would get very complex and hard in exactly the same places: a
bit of text styling is simple enough, in wikitext, in a new parser, and in
wysiwyg. But editing nested tables is already a challange with "real" word
processors, not to mention web-based editors. And when we get into designing
complex templates, using "magic" sections like noinclude, using complex parser
functions and template parameters, and, most of all, using special constructs
defined by extensions, things get extremly complex. For example, extensions
could rely on xml represenations, but they would have to provide gui interaction
elements to create and edit them. I truely believe that trying to buld a gui
framework for this would be much much harder than all the tricky stuff a good
wikitex parser has to deal with. With a "simple" parser, as well as with
"naive"
wysiwyg like fckedit, it's easy enough to get to 90% of what wikitext can do.
Getting to the 99.9% we need to make this usable for wikipedia is HARD. And
doing it as a gui system is harder, imho.
-- Daniel