At the beginning I should mention that I'm a CKEditor core developer, thus my opinion may not be fully objective :).
The state of HTML editing AFAIK hasn't changed for the last few years. Browsers vendors have spent little time fixing bugs - so little that most of the oldest bugs on CKEditor trac that were caused by browser issues are still valid and most of hacks we've ever created are still required. And I don't only mean IE 7 or 8 which we still support, because in fact IEs may not be the worst. I haven't checked that precisely, but I think that thanks to general improvements for DOM APIs in recent IEs versions they may require less hacks than other browsers, because its editing support seems to be the most stable and complete. E.g. the ugliest hack ever is needed for Webkit browsers (see: Webkit bug and closed CKEditor ticket) and this bug is 5 year old. What's more - this isn't an edge case or unlikely scenario - this issue makes it impossible to create whole range of selections - e.g. inside an empty inline element IIRC.
So, unlike the web technologies in general, HTML editing stands where it was left 10 years ago. The same bugs, the same missing features, the same... markup. Guess what is created by the fontName command? <font face=""> - yep, not joking. At least browsers are very consistent here... But the consistency very quickly disappears.
What about the spec? There's a draft, but it does not help at all - it just standardizes the current state, which as we know does not look very well. And AFAICS, the draft is dead.
And there's one more thing that worries me - direction in which editing goes. Google uses contenteditable in Gmail (no, Google Docs is not built on contenteditable), so it does not care about HTML output. Apple reuses HTML editing component in their email app for iOS and perhaps in Mail for MacOS (because I see the same specific behaviours). Mozilla reuses Gecko in Thunderbird and I it wouldn't surprised if Microsoft does the same in Outlook. All of them do not care about HTML output. These engines are made to understand every crap rather than fix it and the HTML Editing draft is all about it.
Thanks to all of that, we can see new issues like this one. In the Blink/Webkit bug report I summarized whole range of incorrect (from our POV - devs who care about HTML) results when pressing backspace. It is designed to look nice (although it does not), but the HTML and editing APIs are not important.
I don't care about this. I need an editor!
The solution to all of that is fixing everything after browsers and/or replace their native implementations by our own. For the last 1.5 years I've been working nearly exclusively on filtering and normalizing input and output. In CKEditor 4.0 we rewrote entire pasting and HTML insertion processes and in recently released CKEditor 4.1 we introduced the Advanced Content Filter which adapts input data to the editor configuration. So the less features are enabled, the less will be allowed in HTML. Check this sample - try to paste/write/create crappy HTML.
Of course, there's still a room for improvements. E.g. we are not able to filter data immediately during editing. If browser (like Webkit) creates a mess we can fix that on output, but in fact we haven't decided to do that because filtering is really complex process and could spoil the performance. We limit input and user actions so one day we will implement our own backspace/delete handlers to prevent browsers from messing our HTML. That's the only solution and this is why there are just 2 or 3 good WYSIWYG editors.
Anyway, nearly nothing has changed in browsers' HTML editing implementations, but a lot has changed in WYSIWYG editors world. I advice you to check them again if you base on your experience from few years back.
