> I maintain that users are not going to want to hold both models in
> their heads.
I didn't say users should hold two models in their head. I didn't
propose two.
> As far as I remember, I've never had anyone ask me if it would be
> possible to combine both systems.
http://lists.gnu.org/archive/html/gnu-emacs-sources/2009-11/msg00010.html
> It's the latter that I predict will be hard work
No doubt.
> If the two are to coexist, how are the two models of undo going to
> interact?
You've misunderstood something, see the first answer above.
> How will history-discarding work well for both models?
Discussed already in the thread.
> If you want to integrate undo-tree into Emacs, whilst also keeping
> the traditional undo system (presumably an essential requirement),
> why not keep the elegant and conceptually simple (biased personal
> opinion :-) `buffer-undo-tree's data structure, but make the nodes
> point to the appropriate changesets in buffer-undo-list?
That may be an option.
> That way most of the undo-tree code, including all the tree-related
> features, will work unchanged or with very minor changes.
I know the value of starting from code that works now.
> Reimplementing undo-tree from scratch on top of
> undo-(equiv|redo)-table smacks a little of NIH syndrome to me.
Nice strawman argument.
> I think you're still missing the main point I was making. Because
> buffer-undo-tree isn't treated specially by GC, even unreferenced
> *deleted* markers (e.g. from `delete-overlay') continued to exist in
> the undo-tree. Undoing a changeset containing a marker-update entry
> for one of those deleted markers would resurrect the deleted marker,
> recreating overlays, and causing general havoc.
You may have misattributed the root cause of those problems.