>>> I'm not sure I understand.  IIRC 'window-next-buffers' always returns
>>> nil unless you invoked 'switch-to-prev-buffer' before.  It serves to
>>> "navigate" a window's buffer list, in particular, to "undo" preceding
>>> 'previous-buffer' calls when overshooting.  'switch-to-buffer' is not
>>> part of such a scenario.
>>
>> A new option should always keep the fixed order, even when users use C-x b
>> to visit a buffer that appeared in the window before.
>
> What is the "fixed order"?  When I use C-x b, that buffer becomes the
> one most recently shown in that window.

The fixed order is similar to how tabs work in web browsers.
It would be unexpected when switching to a tab will always
move it to the end of the tab line.  This is why it's unexpected
for C-x b to move tabs when tab-line-mode is used.

>> The problem is that there is no function that is called after
>> set-window-buffer to reset the order of prev/next-buffers.
>>
>> set-window-buffer works that way that before changing the window buffer
>> it calls record-window-buffer.  But record-window-buffer has
>> no information about new-buffer.  So it can't reorder prev/next-buffers
>> based on new-buffer that will be displayed in this window.
>>
>> Then later set-window-buffer sets window's buffer,
>> but after that it doesn't call any function like
>> record-window-buffer that could reorder prev/next-buffers.
>>
>> Then maybe possible to add such reordering after calling
>> set-window-buffer?  I mean such places as after calling
>> set-window-buffer in window--display-buffer, and after calling
>> set-window-buffer in switch-to-buffer.
>
> Then give 'record-window-buffer' a second argument - the new buffer to
> be shown.  I'm a bit reluctant to work in this area - the introduction
> of 'push-window-buffer-onto-prev' has obfuscated the code considerably
> for no apparent use (at least one that I could understand).

Ok, let's add a second argument to 'record-window-buffer'.
I'll do this in a separate feature request for a new option
that will keep the fixed order for C-x b
since it's quite different from the wrapping option.

> I see no problems with it.  After C-x b *foo* I want to return to *foo*
> via 'previous-buffer' after switching to *bar* via a second C-x b.  What
> would you want to see instead?  Maybe I still misunderstand you.

Selecting a buffer via C-x b still uses the sorting order of buffers
by the most-recently-used.  So after C-x b *bar* you still can easily
return to *foo* by C-x b RET.  But the proposed change makes sense
when using tab-line-mode where C-x b messes up buffer tabs.

> I think 'switch-to-prev-buffer-wrap' already confuses things.  Wrapping,
> for me, means to wrap around like when navigating on a ring of buffers.
> Whether this should include buffers never shown in the window before is
> a different issue IMO.  And whether C-x b should change the order is yet
> another issue.  So maybe we need three options instead of one...

I can't imagine why anyone would need wrapping when C-x C-left
will visit hundreds of buffers never shown in the window.
So we need only two options: wrapping buffers shown in the window,
and to keep the fixed order of C-x b.  So I will create a new request
for the fixed order of C-x b.  And here is the final patch for wrapping: