I have a possible fix for this now, currently on the
branch fix/undo-point-in-wrong-place. I waiting for some other feedback
on my code before I squash and merge it, but if you have the chance it
would be good to know if it works.

Phil

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> No problem Phil.
> Thanks for looking into this.
> On 20 Nov 2015 7:51 am, "Phillip Lord" <phillip.lord@newcastle.ac.uk> wrote:
>
>>
>> It is my commit after all. I will work on it as soon as I can. Had a nasty
>> cold for the last few days.
>>
>> Phil
>> ________________________________________
>> From: emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org
>> [emacs-devel-bounces+phillip.lord=newcastle.ac.uk@gnu.org] on behalf of
>> Karl Fogel [kfogel@red-bean.com]
>> Sent: 20 November 2015 01:24
>> To: Phillip Lord
>> Cc: Artur Malabarba; emacs-devel
>> Subject: Re: Apparent regression on the undo command
>>
>> phillip.lord@russet.org.uk (Phillip Lord) writes:
>> >Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> >> 2015-11-19 9:47 GMT+00:00 Phillip Lord <phillip.lord@russet.org.uk>:
>> >>> I'll try and see if I can automate the problem and
>> >>> run a bisect.
>> >>
>> >> The following works for me. When called on the *scratch* buffer it
>> >> returns non-nil if the problem occurs.
>> >>
>> >> (progn
>> >>   (kmacro-call-macro nil nil nil [134217788 11 14 14 11 67108911])
>> >>   (equal (point-min) (point)))
>> >>
>> >> That macro simply calls M-< C-k C-n C-n C-k C-/
>> >
>> >
>> >I tried various combinations -- works interactively but fails in batch
>> >either because *scratch* hasn't been initialized, or undo appears to
>> >work wrongly.
>> >
>> >No worries, it's easy enough to test by hand, and am doing so.
>>
>> Any luck?  FWIW I'm noticing the bug too, in emacs-25 branch built from
>> commit c210b8b128c.
>>
>> Best regards,
>> -Karl
>>
>>