conflict resolution for concurrent modifications of the same object on different domain controllers are resolved first by local timestamp (unreliable) and then by GUID order (arbitrary) and in both cases mean that it's possible for someone to make a change to an object that is reflected in local reads for a period of time, but then "erased" and forgotten after replication, tl;dr: this approach provides basically no meaningful consistency at all
my understanding is that conflict resolution is done by all domain controllers comparing the USN of each object and replicating the object with the highest USN.
lww is arbitrary, because (a) it's unknowable if some local state is actually valid, and (b) resolving conflicts is destructive
conflicts cannot be resolved in general without additional information from the application
in an lww system if a bit of data loses in an lww contest, that data was not just stale, it actually becomes invalid
if you set a=1 and then do a bunch of operations based on the idea that a=1, and i set a=2 and then do a bunch of operations based on the idea that a=2, and lww resolves that my a=2 wins over your a=1, then after that merge, your a=1 is not just stale, it's entirely invalid, erased from history. at no point did a ever equal 1. anything you did with that assumption is similarly invalid. and lww provides no way to manage the causality implications of that decision.
it's fine for many use cases but it's not a general-purpose solution.
