Thanks for your reply, Toby. I appreciate your wisdom on this topic.

> Perhaps I felt that duplicating the entire subtree would make for a
> needlessly complex tree.

I find one limitation in undo-tree is that a buffer state that was two
edges away becomes an arbitrary number of edges away, because
undo in region reaches arbitrarily far back.

Alternatively, after an undo in region, you could display it like:

  |
  |
  A'
  |\…
  |

Literally with the ellipsis. Traversing that edge would take you back
to the parallel tree you came from:

  | …
  |/
  A
  |
  |

The parallel trees look the same after all. I don't think the user
usually cares where is the root at which they join together, although
there are probably ways to display that.

> The implementation and maintenance overhead of designing a system
> that simultaneously supports two largely incompatible undo models
> doesn't seem worth it to me.

I'm not sure why you say they're largely incompatible.

> From memory (and git logs), I think that without this mechanism
> undo-tree used to sometimes resurrect dead markers when undoing. A
> lisp package might delete a marker from a buffer and drop all
> references to it, expecting it to be garbage collected. But because
> it was referenced from buffer-undo-tree (a strong reference, rather
> than the specialized buffer-undo-list weak reference), the marker
> never got GCd. Undoing a changeset containing the deleted marker
> would then restore the marker. I remember this created all kinds of
> havoc with overlays.

Sounds like bug 16818, which affected the builtin undo system too. It
is fixed in the upcoming Emacs 24.4. undo-tree may require an
analagous change, since it doesn't use undo-make-selective-list.

I don't think this bug has anything particular to do with
compact_undo_list splicing out marker adjustments in GC. Maybe the
undo-tree-object-pool makes the bug less probable because it allows
some problematic marker adjustments to be removed earlier during GC
instead of later during undo history truncation.

The undo-tree-object-pool code looks like a correct, albeit
convoluted, mimicry of compact_undo_list, but I don't see an actual
problem either solves.