> Please try with more buffers than initial 2 (*scratch* and *Messages*),
 > e.g. with *info* (just `C-h i'), I get
 >
 > 1 ... current: *scratch* ... window-buffer: *scratch*

... which is something you probably don't even want - it comes from
'get-buffer-create' when making the *info* buffer ...

 > 2 ... current: *scratch* ... window-buffer: *info*
 >
 > which is in an inconsistent state,

... not really - look at the backtrace:

   foo()
   run-hooks(buffer-list-update-hook)
   record-window-buffer(#<window 3 on *info*>)
   set-window-buffer(#<window 3 on *info*> #<buffer *info*>)
   window--display-buffer(#<buffer *info*> #<window 3 on *info*> reuse ((inhibit-same-window)))
   display-buffer-same-window(#<buffer *info*> ((inhibit-same-window)))
   display-buffer(#<buffer *info*> (display-buffer-same-window (inhibit-same-window)))
   pop-to-buffer("*info*" (display-buffer-same-window (inhibit-same-window)) nil)
   pop-to-buffer-same-window("*info*")
   info(nil nil)
   funcall-interactively(info nil nil)
   call-interactively(info nil nil)
   command-execute(info)

'pop-to-buffer' can "reasonably" select the window and thus implicitly
make its buffer current only _after_ the buffer has been displayed via
'display-buffer-same-window'.  I say reasonably because we could make
the buffer current earlier but this doesn't strike me as a very good
idea.  It would constitute an incompatible change in the internal
behavior of 'pop-to-buffer'.

 > and after typing `q' the hook is called 3 times
 >
 > 3 ... current: *scratch* ... window-buffer: *scratch*
 > 4 ... current: *scratch* ... window-buffer: *scratch*
 > 5 ... current: *scratch* ... window-buffer: *scratch*

Look at the backtraces:

3 ... current: *scratch* ... window-buffer: *scratch*
   run-hooks(buffer-list-update-hook)
   record-window-buffer(#<window 3 on *scratch*>)
   set-window-buffer(#<window 3 on *scratch*> #<buffer *scratch*>)
   set-window-buffer-start-and-point(#<window 3 on *scratch*> #<buffer *scratch*> 1 #<marker at 1598 in *scratch*>)
   quit-restore-window(nil bury)
   quit-window()
   Info-exit()
   funcall-interactively(Info-exit)
   call-interactively(Info-exit nil nil)
   command-execute(Info-exit)

This one comes from replacing the *info* buffer with *scratch* in the
window.

4 ... current: *scratch* ... window-buffer: *scratch*
   run-hooks(buffer-list-update-hook)
   select-window(#<window 3 on *scratch*>)
   quit-restore-window(nil bury)
   quit-window()
   Info-exit()
   funcall-interactively(Info-exit)
   call-interactively(Info-exit nil nil)
   command-execute(Info-exit)

This one comes from selecting that window.

5 ... current: *scratch* ... window-buffer: *scratch*
   run-hooks(buffer-list-update-hook)
   bury-buffer-internal(#<buffer *info*>)
   quit-restore-window(nil bury)
   quit-window()
   Info-exit()
   funcall-interactively(Info-exit)
   call-interactively(Info-exit nil nil)
   command-execute(Info-exit)

And this one comes from burying the *info* buffer.  What should we do
instead?

 > And there is the workflow how to break the correct order
 > of `C-x <right> C-x <left>':
 >
 > 1. Create *info* buffer: `C-h i' and quit `q'
 > 2. Split windows `C-x 2' or `C-x 3' (both windows display *scratch*)
 > 3. Check that `C-x <right> C-x <left>' correctly returns to the original
 >     buffer *scratch* in the first window.
 > 4. After `C-x o' in another window `C-x <right> C-x <left>'
 >     doesn't return to the original buffer *scratch*.
 >     It displays *info*.

Evidently, this comment for 'record-window-buffer'

;; The following function is called by `set-window-buffer' _before_ it
;; replaces the buffer of the argument window with the new buffer.

had its purpose.  Please try the attached patch.

Thanks, martin