bug#31695:

[martin rudalics <rudalics@gmx.at>]

 > I took a look, but as expected, got lost among twisted little
 > passages, all alike.  It looks like the problem might be with the
 > insane dance we perform when entering recursive edit in the
 > minibuffer, where we save and restore the window configuration of the
 > selected frame, and also of the frame that serves as the minibuffer
 > frame for the selected frame.

This is indeed a very troublesome aspect because we restore the
current buffer (which is per se not related to window configurations)
twice.  Basically, it should suffice to save/restore selected frame
and current buffer around saving/restoring the configuration of the
minibuffer frame, but I'm afraid that this might lead to subtle
changes that would go undetected for another six years.

The real problem is described in this comment

	/* BUF_PT (XBUFFER (new_current_buffer)) gives us the position of
	   point in new_current_buffer as of the last time this buffer was
	   used.  This can be non-deterministic since it can be changed by
	   things like jit-lock by mere temporary selection of some random
	   window that happens to show this buffer.
	   So if possible we want this arbitrary choice of "which point" to
	   be the one from the to-be-selected-window so as to prevent this
	   window's cursor from being copied from another window.  */

and indeed my change which causes the current bug executes

	  old_point = BUF_PT (XBUFFER (new_current_buffer));

and later does

       if (!EQ (XWINDOW (data->current_window)->contents, new_current_buffer))
	Fgoto_char (make_number (old_point));

where old_point is BUF_PT obtained from the other frame showing NEWS -
the one at BOB.  And it does this when restoring the configuration of
the minibuffer frame.  When restoring the NEWS frame the wrong setting
is already cast.  Replacing the last two lines with

       if (!EQ (XWINDOW (selected_window)->contents, new_current_buffer))
	Fgoto_char (make_number (old_point));

fixes both the present bug and the behavior from Bug#12208 so if I do
not find a better solution I intend to use that.  IMHO the idea behind

   new_current_buffer = data->f_current_buffer;

is inherently botched when restoring a frame where that buffer appears
on another frame.

 > Another potential culprit is
 > select_window_1, which added the call to set_point_from_marker at its
 > end, something that wasn't there in Emacs 24.2.

This might be related but I have not found any impact yet.

 > In any case, the immediate cause of the problem is that when redisplay
 > is entered the offending window is selected and has its point set at
 > BOB.  So redisplays redraws it accordingly.
 >
 > Btw, note that if you modify the recipe to do it from frame $a, the
 > problem doesn't happen.  Which seems to imply that this is somehow
 > related to the order in which redisplay redraws frames.  I think.

I'm quite sure this is the case.  To make it happen from $a you have
to set the window point of $b first, then in $a choose another window
point and then start the minibuffer rigmarole.

martin