There is a definite issue concerning reverse merges from the branches' own history. In this test, the merge that behaves unexpectedly is the final 'reintegrate' shown in the following graph (which appears as a comment in that test).

The plain merge does in fact merge r15, the reverse merge of r8. (It doesn't print any evidence of it there, because the result is a no-op, but if we change the test to make another modification to that file, then we can see it.)

The root issue here is that a reverse-merge of a change from the shared history[1] history is interpreted by 'reintegrate' as a user error to be diagnosed, by plain 'merge' as just another change to be merged, and by the current 'symmetric' code as just another change to be merged.

Without going into *why* they should behave differently right now, I think it is clear that the 'symmetric' merge should in this case behave like the 'reintegrate' merge and detect and report the situation.

So I'll take a stab at fixing that.

[1] We probably have very similar issues dealing with a reverse-merge of a change from the history of one branch or the other (after their youngest common ancestor).