bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> But displaying a temporary buffer could add a "tab" to the end of the
>> tab-bar, this means at the end of the list of next-buffers:
>>
>> [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
>> prev-buffers                                         current-buffer
>
> The problem with this approach is as follows: The list of next buffers
> is usually empty because it contains only the buffers visited while
> navigating the list of previous buffers backwards in time.  It's main
> purpose is to revert any overshooting during such navigation.  But
> this means that when you add your temporary buffer to the (usually
> empty) list of next buffers, overshooting while reverting the
> overshooting will get you to that temporary buffer immediately.

What buffer does it show now in this case?  Is it a more predictable
buffer than would be in case of a previously displayed temporary buffer?

>> After exiting from this temporary buffer, it could be kept in the
>> list of next-buffers:
>>
>> [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
>> prev-buffers          current-buffer                    next-buffers
>>
>> Then returning to prev-buffers (e.g. with kill-buffer) will not visit
>> this temporary buffer.  But display-buffer-reuse-window could look for
>> a previously displayed buffer in the list of next buffers.
>
> The main purpose of a window's list of next buffers is that of undoing
> a 'switch-to-prev-buffer' step.  I have no idea which consequences
> your proposal could have apart from the one I sketched above.  I'm
> already no great friend of
>
>      If there is no recent invocation of `switch-to-prev-buffer' that
>      can be undone, this function tries to show a buffer from the
>      buffer list of the frame WINDOW appears on ...

And this is usually some random unpredictable buffer.

> but this comes from an attempt to model buffer switching like 'undo'
> does.

undo/redo is a good analogy.