Since you mentioned Haskell...
No matter what order these patches are applied in, they're guaranteed to converge to the same ultimate result -- it's a lot like using a distributed version control system, except that you do a branch and merge on every keystroke, in a way that isn't slow and doesn't break horribly.
What's the connection to Darcs? A faster less-powerful version since branches won't be long-lived and not all that much commutation should be necessary?
It's pretty similar to Darcs-style patch manipulation. I've only skimmed some introductory material on exactly how Darcs does it, but it looks a lot like what Wave does:
Make patches invertible.
Define a function T :: Patch -> Patch -> Patch that transforms one patch to apply to the document after a second patch has already been applied to it.
With these primitives, you can arbitrarily re-order patches. That's not quite the way I'm doing it, though. I represent the document as a tree of atoms, each one with a unique id and a pointer to a predeces...
Whpearson recently mentioned that people in some other online communities frequently ask "what are you working on?". I personally love asking and answering this question. I made sure to ask it at the Seattle meetup. However, I don't often see it asked here in the comments, so I will ask it:
What are you working on?
Here are some guidelines