Note that it is used in applications such as TextEdit on MacOSX for example. And it's quite practical when you are for example quoting the text of a Web page, but you want to copy only part of it. It's a lot easier than multiple cut and paste from one window (context) to another one. 

There might be issues for copy markup, but for copy text only it is quite cool.

That said, maybe a mechanism where you could have an incremental copy would be cool. 

1. Select and Copy
2. Select and Copy = OldCopy + NewCopy

You add the select to the buffer, a bit less practical than the previous multi-range.

The issue here is only the author-exposed selection.  UAs can still allow the user to select multiple things at once, as long as only one range is exposed in the Selection object.  User actions like copy and paste could still deal with the whole visible selection.

At some point we might want to support some way of exposing non-contiguous selections to the author, but the current way is just far too error-prone.  Gecko developers themselves don't even support multi-range selections sanely.  Ehsan had a demo where when he selected three things at once in a contenteditable region, and ran three different execCommands.  The first one affected only the first part of the selection, the second affected only the second part, and the third affected only the third part.  He had no idea why.  (Maybe execCommand was removing the affected range from the selection's list and re-adding it at the end?)

Moving Selection-related bugs to editing: see bug 14248, bug 14252.

http://dvcs.w3.org/hg/editing/rev/b1598801692d