Wysiwyg API vs various textarea enhancers
The Wysiwyg API is supposed to be a supermodule to replace the various WYSIWYG and non-WYSIWYG individual textarea enhancement modules such as FCKeditor, TinyMCE (whose module development has been halted in favor of Wysiwyg API), markItUp! (of which I am now the unworthy primary contributor), etc. The idea is that one single module is capable of modifying the textarea to use any given enhancer's JavaScript files, so Wysiwyg API can, as a single module, drive FCKeditor, TinyMCE, and any other of the ten or so systems it supports.
Wysiwyg API seems to have a lot of buzz, with some even saying it's core-bound, so I have something of a duty, I suppose, to eventually get mIU! working with it. I must admit I haven't really looked at it much. I recently gave it a try on a client's project, but I wasn't happy with what I found. The biggest problem I saw was that the setup form flooded me with options, many of which weren't relevant for the system I was trying to use - it seems like the setup has been written primarily for TinyMCE. This means that other systems may not support all the options that are on the setup screen, or that options which other systems may use that TinyMCE does not support cannot be configured from the setup screen. Of course, having only looked at the surface so far, I could be totally wrong about this and there is a way for each system to modify this form to suit its capabilities. But it'd be a real bummer if it turned out the cost for Wysiwyg API was the ability to configure the system you're using to properly suit its capabilities.

mui currently has basic
mui currently has basic support in the wysiwyg development branch. I'm currently working on getting Markdown support functional over at #397994. However, the whole settings system is under revision, as I believe sun is looking at doing something similar to Views 2 (which would be awesome).
Of course not! The current
Of course not!
The current editor configuration is still based on the previous TinyMCE module. Originally, I thought that it might be possible to unify the editor configuration similar to how Wysiwyg API unifies the loading/attaching/detaching of editors and editor plugins. However, that is not sufficient at all and we badly need to address this issue in Allow to configure advanced editor settings.
This will effectively be a major module rewrite on the PHP side, which adds a dependency on CTools (Wysiwyg API's editor/plugin system was already forked from Panels in the first place) and turns editors as well as plugins (and possibly also wysiwyg profiles) into objects.
Daniel F. Kudwien
unleashed mind