Osm changes are already expressed as atomic changes to each version of an object. Reasonably resolving a conflict where two different edits increment the same version of the same object is a difficult problem (the typical way it is currently done is reject the later edit and force manual review/fixup of the conflict).

If someone adds a road and joins it to an existing road at existing point A, while someone else adds a duplicate of the same physical road and joins it at existing point B, it's going to take a rather aggressive heuristic to automatically discard one of them.

Your comment reminded me of managing merge conflicts in git (or any distributed source control system)

With conflicts, best way to resolve is a human manually deciding how to merge (which part of commit A & which part(s) of commit B to include) :D

That makes me think that applying a machine learning algorithm to suggest conflict merge fixes would be a fun little project.

Time of entry is the canonical index.