Once upon a time, when people started building web content management systems that actually allowed you to manage the content (and not just publish it), there were hundreds of editors. Vendors were quick to recognize that while HTML was a lot easier than SGML, there weren't going to be a whole lot of people actually doing all of it directly in <h2>Hyper Text Markup Language</h2>.
And at that time, Internet Explorer had some handy features which allowed developers to quickly whip up a rich text editor. Netscape Navigator had lost the browser wars and represented a negligible percentage. Microsoft still had a fairly recent version of IE for Mac. And Linux, well, nobody used Linux on the desktop in the enterprise, really. In short, there was no real reason not to use the IE-specific functionality. Especially since building everything for an editor from scratch was a lot of hard work. And even for those who didn't use IE's niceties, there wasn't a real need to test on any other browsers.
Then came Firefox, and everything changed. And IE7 made it worse.
Suddenly, cross-browser compatibility was an issue again, and a developer-intensive one, at that (like I said, building a rich text editor is a lot more complicated than you'd think, and building one that works in every browser is nearly impossible). Vendors and open source projects alike were reeling from this changed reality. And fast-forwarding a few years, this means that by now, all but a few CMS products have thrown in the towel. You can have whatever UI you want, but the editor is likely going to be either TinyMCE or FCKeditor. (We're coming out with a matrix of vendors' editors shortly.)
Now, I could go on with a lengthy exposé on which is better for which purpose, but the differences are Tiny, and we describe them in our research, so FCK it. (I couldn't resist that). If you really want to, you can usually swap one out for the other -- though this will often take some effort, so make sure you have good reason to do so.
It's also tempting to discuss some of the less used alternatives, such as Ephox (which is used by many high-end systems because, as my colleague Kas Thomas tells me, it's considered "top-of-the-line," not in the least because of its extensive Java API.) Or Xinha, the successor to HTMLarea. Maybe .NET favorites Telerik RadEditor (now part of a larger set of .NET components, and therefore usually showing up in bespoke .NET applications) and Ektron's eWebEditPro (which used to be everywhere, but most vendors have probably decided they'd rather not pay a licensing fee to a competitor).
In the end though, if you're sitting through a vendor demo, watching some pre-sales engineer type in "Hello world," then changing it to bold, the question to ask is simple. Is this FCK or Tiny?
Only if it's something else should you check how it stacks up. Given the fact that both Tiny and FCK have their drawbacks, and the integration of either with a CMS is unlikely to be very tight, there are plenty of reasons why "something else" might be better or worse (and browser compatibility is just one of the highlights). But with many shortlists, you can move on to more pressing issues.
With the recent flurry in acquisitions, there's a lot of talk about consolidation in the web content management space. However, for every vendor acquired, there's a new product on the horizon. The real consolidation isn't in products or projects; it's in components. Know about Lucene and Solr; and Tiny or FCK -- and spend your time on the real differences.