Red herring involving buffer-display options

From emacs -Q, put the following in *scratch*:

  (setq erc-join-buffer 'window)
  (erc :server "testnet.ergo.chat" :nick "tester")
  (erc :server "testnet.ergo.chat" :nick "dummy")
  (list-processes)

Do M-x ev-b RET and notice three separate connections.

At first, I was certain this meant old demons, but after noticing that
wrapping the whole thing in a `progn' produces the expected results, I'm
convinced this actually isn't an ERC issue.

For example, if you put the following in some file, like a /tmp/foo.el:

  ;;; /tmp/foo.el -*- lexical-binding: t; -*-
  (defvar my-var nil)
  (selected-window) ; just for reference in trace output
  (select-window (display-buffer "*Messages*" t))
  (push 'a my-var)
  (display-buffer "*Messages*" t)
  (push 'b my-var)

And then do

  $ emacs -Q -batch -eval '(progn (find-file "./foo.el") (eval-buffer nil t))'

You'll get something like

  my-var
  #<window 1 on foo.el>
  #<window 4 on *Messages*>
  (a)
  #<window 1 on *Messages*>
  (a a)
  #<window 1 on *Messages*>
  (b a a)

(line breaks added for emphasis).

Whatever's going on [1], this behavior seems to be present at least as
far back as 27.2, so it's likely old news (didn't bother checking the
bug archives, but perhaps I should). For now, I guess the practical
takeaway is: couch top-level window-related shenanigans in a `progn' if
intending to `eval-buffer'.

If anyone knows more, please share or open a bug report if you think
that's justified. Thanks.


[1] FWIW, this doesn't trigger the same "deja vu" phenomenon:

    $ emacs -Q -batch ./foo.el -eval '(eval-buffer nil t)'

    Also, the two `display-buffer' lines can be swapped out for these:

    (set-window-buffer (select-window (split-window)) "*Messages*")
    (set-window-buffer (next-window) "*Messages*")