Even after fixing #65 inconsistency detection is still flaky. This happens when the same PCS triples are involved in multiple inconsistencies. For example, consider the base=abc, left=bac, right=acb. This is a move conflict, b is moved both to the start and the end of the list.

The pcs triples (simplified to exclude parent) then look like this:

base: (START, a), (a, b), (b, c), (c, END)
left: (START, b), (b, a), (a, c), (c, END)
right: (START, a), (a, c), (c, b), (b, END)

Right now, we resolve all inconsistencies of a certain type (parent, predecessor, successor, in that order) for each PCS in the iteration, as opposed to vanilla 3DM which just resolves a single inconsistency per iteration. A problem occurs when PCSes are involved in both predecessor and successor inconsistencies, which may cause an inconsistency to go unnoticed. For example, if we iterate over the union of the pcs sets above in the following order:

// iteration 1
pcs = (b, a)
others = [(START, a)] // getOtherPredecessors
// remove (START, a) as it is in base

// iteration 2
pcs = (b, END)
others = [(c, END)] // getOtherPredecessors
// remove (c, END), as it is in base

After these two iterations, both (b, a) and (b, END) have been iterated over. Therefore, the hard inconsistency on the successor to b that occurs between these two specific PCSes will be missed. With another iteration order, it may be caught, but iteration order should not matter.

Again, this only appears to affect move conflicts, which we can't really solve anyway. But, if it's not handled consistently, then the same move conflict may cause a crash one time, and an incorrect merge another time.