This can be solved to an extent by the "invisible text area"[1] trick. Here, whatever text is inputted or pasted goes directly to an invisible text area. And from that it is appended to the CE div/iframe that's is shown to the user. I think Cloud9IDE[2] uses this technique.

That and the way every browser reacts to the enter key press. Firefox appends <BR>, Chrome appends <Div> and IE[3] appends <P>.

[1] I don't know where I read about this. Sorry.

[2] http://cloud9ide.com/

[3] The IE behavior is similar to MS Word.

For Webpop (http://www.webpop.com) we ended up going with TinyMCE as our rich text editor after trying both CKEditor and WymEditor because Tiny was the only one that handled pasting into the edit area fairly well.

It's really tricky to handle right, and the Paste plugin for Tiny has to use a lot of tricks to do it properly. The onpaste event doesn't really work for this, because even in browsers that supports it, it just gives you plain text with no formatting. Same with a hidden textarea.

It's ok if you want to strip all styles, and then let your user go though and apply all the same styles from his Word document manually once again (frustrating!), but otherwise it wont cut it.

The paste plugin does a lot of browser specific stuff, but basically handles it by creating a contenteditable div and redirecting the paste event into that, then grabbing the horribly broken HTML browsers produce when pasting from anything and cleaning it off before moving it back to the place the user pasted too...

Agree contenteditable is not implemented consistently across the browsers and with Aloha Editor we try to reduce that pain... Did you test the most recent paste plugin? https://github.com/alohaeditor/Aloha-Plugin-Paste/tree/maste.... This plugin provides a methode to register paste handlers the clean the pasted content. Imho the MS word copy/paste should work quiet good in most cases. Unfortunately there are only few other handlers implemented yet, so coping HTML may remain unhandled...