Depends what you're trying to keep concurrent, and your concurrency policy. OT is great for optimistic concurrency on complex structured documents, but probably overkill for simple models (like to-do items) with simple attributes (like title, is-done etc.). For that you could get away with - eg. a revision counter on the model.

Because of the performance implications of different concurrency, you probably don't want it baked too deeply into any framework, since there's some stuff you definitely want strict conflict/error resolution on, and other things you don't.

Essentially, that's our take as well. However, we do have a plan for dealing with conflicts and missed updates soon -- probably after Thoonk.js 1.0 slated for late December. Here's how I replied to this question on the blog comments:

The data in the thoonk feeds are never edited locally on the client. Any user-actions that change data go out as a websocket rpc call, and get placed in a job queue. The workers validate the data, check ACL, and then update the corresponding feeds, which then bubbles back up to the user. This happens nearly instantly, and the feed updates are atomic. If two users edit an object, then the last edit wins. For the data we have, this isn't a problem. However, we've got a plan for dealing with concurrency and conflict resolution in the future so that we can can handle being offline for periods of time, and detecting and dealing with conflicts. --

For &bang in particular, we'll probably just let the user that owns the task resolve the conflicts. "You queued an update to this task while offline, but Bob edited as well. Which version would you like to keep?" In general, you can't edit eachother's data, but you can add to it, so it isn't much of a problem.

Thoonk 1.0 will have update history and incrementing revision numbers for feeds that will give you enough information to resolve your conflicts (whatever the method you choose is) and will help your app recognize and retrieve missed updates.