bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active

[Drew Adams]

> > > Perhaps we should modify the minibuffer code
> > > to note which window should be current after
> > > the completion or abortion of the minibuffer
> > > read action.
> 
> > Isn't that simply "the window which was selected
> > before entering the minibuffer"?
> 
> Most of the time, yes.  If that window no longer
> exists on termination of the minibuffer, or we've
> moved to a different frame, things aren't so simple.

You can and will ignore this, but IMO _all_ of
the above is misguided and short-sighted.  "Isn't
that simply...?" is just plain wrong - both the
question and any single answer.

It isn't "simply" _anything_ you can preconceive.
It's _whichever window ended up_ selected after
using the minibuffer.  Nothing more, nothing less.

Let's-hard-code-which-window-should-be-selected
is maybe related to the fact that I can no longer
use Emacs > 26.3.

What's wrong with attempts to predetermine which
window should be selected after a minibuffer
read?

It's the presumption that a minibuffer's only
purpose is to return something read, and that the
state of Emacs, including which windows exist and
which should be selected, should be the same as
before the minibuffer was entered - or should be
any other predefined state.  The selected window
here shouldn't be determined formulaically.

This completely prevents or interferes with code
that _does things_ while the minibuffer is active
with the intent of changing such state, e.g., the
intent to change the selected window, and not
just till minibuffer reading is finished.

There.  I've said it again.  And clearly Emacs
won't be going back to its former freedom in
this regard - 1000 ships have sailed.  But IMO
this is a great loss.  And it comes, I think,
from assuming that others use existing behavior
only the way you do.

My use of Emacs relies on doing lots of things
while a minibuffer is active - including things
that you might do only when it's inactive.  And
the changes I make while its active shouldn't
be overridden when a minibuffer is exited.

And yes, this can include changing the selected
window and focused frame.  I want to be able to
do that myself, interactively or by definition
from the function that invoked the minibuffer.

To my mind you've hobbled Emacs - specifically
its minibuffer, just as much as if you'd poked
out its eyes or cut off its legs.

If you'd really wanted to provide only some
_default_ behavior wrt choosing the window to
select here, then you'd have done that.  You'd
have provided some way (e.g., a variable) for
code to _prevent_ force-selecting the window
you've predetermined to be the "chosen one".

The Emacs minibuffer was "simply" better
before you simply "fixed" it.