> The "move-after" markers will be at (+ del-pos (length
> inserted-text)) rather than at del-pos.

Right, thanks for catching that flaw.

> I'd have the same comment here, but if we emit a warning for sole
> marker-adjustments in the "non-region" code, we don't really have to
> worry about them here.

If you're saying changes under undo-make-selective-list are not
necessary, remember that currently it can create a list like:

  (nil (#<marker at 141 in *scratch*> . -3) (#<marker at 190 in *scratch*>
. -3) nil (aaa . 141) nil (141 . 144) nil)

I don't think the original recipe of this bug report should generate a
warning. Rather, I had undo-make-selective-list filter out the marker
adjustments so as the above list would have (aaa . 141) at the head.

> I think we should only change the entry corresponding to a deletion
> such that it directly handles all the immediately following
> marker-adjustments

They don't always immediately follow. An integer record can be between
them. For example, at the end of the undo-test-marker-adjustment-moved
test I posted previously, buffer-undo-list is:

  (nil (1 . 4) nil (abc . 1) 12 (#<marker at 7 in  *temp*-216909> . -1) nil
(1 . 12) (t . 0))

Also, (t sec-high sec-low microsec picosec) entries can be in between.
eg it was easy to bring about this buffer-undo-list:

  Value: (nil
   (#("   " 0 3
      (fontified t))
    . 12)
   (t 20985 26927 0 0)
   (#<marker at 12 in foo.py> . -2)
   (#<marker at 12 in foo.py> . -2)
   (#<marker in no buffer> . -3)
   (#<marker in no buffer> . -2))

I suppose some options are:

  * Implement your proposal but skip over the (t ...) and integer
    records
  * Restructure the C code so as marker adjustments are always
    immediately before deletion records
  * Revisit the approach of fixing markers that move to unrelated
    locations.

Let me know and thank you for your guidance.