But the point was: what if you wanted the behavior to be different than what you described. What if the intent was really "increment"?
For example, say you have a list AND a counter. Everytime you add an item to the list, you need to increment the counter, as an invariant of your system.
Of course, it's a contrived example, but you get the point: things can get more complicated and the system may break as a result, unless you're very careful.
We had this problem in our iOS app, solved it by using an array of ints wich are the increment-operations (well, we had uuids on them as well so we could determine what was new and do a proper merge).
But we merge by using differential synchronization (kinda) to resolve local changes and remote changes (to construct a "patch") by keeping an unchanged copy of the upstreams latest version (from the clients perspective).
Good point! I think you'd have to implement a lock of some sort, and check for it in application logic-- that way both can be updated simultaneously... not ideal!
If User A incremented 100, and saved it down; then User B loaded this saved state and incremented 101, it'd be 102.