[saurik]

Ok, with those semantics (and I think I understand the basis implementations that would cause them), do you perform the "resync" step (which has the property that you can at least get the catch-up changes in a single bulk and hopefully fast download for the entire bucket, even with the internal reordering that happened over time) as a single transaction (by locking the persistant store coordinator); and if not, why?

With keeping the objects on separate timelines, do you or can you run into any problems with CoreData inverse relationships? I'd be concerned that my objects would have issues where a change got synced for object A that had it linking to object B, but somehow my application crashed before it got the synchronization for object B sent. I can imagine various reasons why this concern is stupid, including "saurik doesn't understand how CoreData works" (as I only even learned of its existence a couple days ago).

[cloudmike]

There's currently no explicit lock or transaction, but due to the way we're multithreading, multiple changes are propagated back to your context in one shot.

Core Data relationships (including their inverses) that come over the wire can be lazily resolved by Simperium if necessary.