So here's the thing: "merge by value" is unsound. If duplicate prim patches
do not have an identity, then permutivity goes down the drains.
I wonder how I wasn't able to see this before; it's really simple.
Here is the basic example: we have two repos, in one we have a patch p1, in
the other we have p2:>q (which do not commute) and p1 and p2 are duplicates
i.e. they make the same primitive change. We merge them one way and get
p1:>p2:>q, where the names here are supposed to identify patch identity, not
content, so they are invariant under merging and commutation. So now q
depends on either p1 or p2. That means we can commute
(1) p1:>p2:>q <-> p1:>q:>p2
because the conflicting patches always commute. But we cannot commute p1:>q
here because q depends on one of p1 or p2. On the other hand we can commute
p1 and p2 (they directly conflict), so we have
(1) p1:>p2:>q <-> p2:>p1:>q
But to the q conflictor p1 and p2 look exactly the same, so with the same
argument as above we can commute
(2) p2:>p1:>q <-> p2:>q:>p1
(which is also the same as merging the two repos in the other direction).
So p1:>q commutes if preceded by p2, but not if we commute p2 past both, in
direct contradiction to permutivity.
This has assumed that duplicate patches conflict as they do in darcs-1
format. In darcs-2 we get a Duplicate patch instead of a conflictor, but
their commutation behavior is exactly the same as that of conflictors, it is
just not counted as a conflict. So with darcs-2 we have the same situation.