>> There is a remaining problem, and I can't find a way to fix it.
>> When a buffer already appeared in the window before,
>> then switching to that buffer with e.g. 'C-x b'
>> moves it to the end of the list.  Technically
>> this means that window-next-buffers is set to nil.
>
> 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.

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.

>> However, I can't find code that does this.  Could you help
>> to find it?  I already found one occurrence of
>> (set-window-next-buffers window nil) in record-window-buffer.
>> But after adding a condition with switch-to-prev-buffer-wrap
>> it still moves the switched buffer to the end.
>
> If you get me the patch you currently use and a scenario, I'll try.

Ok, here is the current patch that supports the fixed order
for 'C-x C-left' and 'C-x C-right' but still not for 'C-x b':