Account for reflected revisions when performing cyclic merges

For an illustration of this problem, see merge (f) in this diagram:
http://subclipse.tigris.org/files/documents/906/37977/repos.png

The corresponding repository is available here:
http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=8590&expandFolder=8590&folderID=8590

From notes/merge-tracking.txt:
* Account for reflected revisions when performing cyclic merges. For
  example: trunk is branched, then modified, and the branch is brought
  up to date with trunk, then the branch is modified, then the branch
  is merged to the trunk. To avoid repeated merging of changes to
  trunk, only the modification to the branch should be applied to
  trunk. (dlr)

  * Need an API which can refine the requested merge range from the
    branch based on a) what changes the merge from the branch already
    represents on trunk and b) what branch revisions were merges from
    trunk to the branch (which should be avoided, to skip replaying
    changes back to trunk which were made on trunk).

I've got a patch (attached) will implements (a), filtering of
reflected revisions. However, Mark Phippard has pointed out that (b),
while it potentially causes repeated merges to occur, may be necessary
to handle other local mods or conflict resolution which occurred after
a merge.

So, how do we handle this? Seems like we're stuck with a potential
re-merging of an existing set of changes, which is a large part of
what merge tracking is attempting to avoid.