bug#46097: [External] : bug#46097: 27.1; Minibuffer may not be current when running minibuffer-exit-hook

[Drew Adams <drew.adams@oracle.com>]

Great apologies for chiming in here without
having followed the thread.  Please ignore,
if what I say is irrelevant - sorry.
___

The bug report says:

 Open the minibuffer with C-x C-f, switch to another window with C-x o
 and abort the minibuffer with C-] (abort-recursive-edit).
 minibuffer-exit-hook ends up running without the minibuffer being the
 current buffer.

 This may cause problems if a minibuffer adds a cleanup function the hook
 locally, see for example discussion at... The cleanup function fails to
 run in this situation because the local value of the hook isn't considered.

A priori, my opinion is that it's wrong for any
function on `minibuffer-exit-hook' to _assume_ that
the minibuffer window is selected when it's invoked.

If a hook function needs that window to be selected
at some point then it should select it.
___

The minibuffer is largely like other buffers.  It's a
_huge_ mistake (design mistake, user mistake, or other)
to consider that interaction with the minibuffer is, in
general, modal - that the user is locked into _only_
interacting with the minibuffer.

This mistaken assumption is not rare, I'm afraid.
That's presumably because many uses of the minibuffer
are simple, and seem to be just type-input-then-RET at
a prompt, or type-and-complete-input-then-RET.

That common use case can mislead users into thinking
that that's the "normal", or a "required", behavior.
And that's quite limiting.

And if someone with that (mis)understanding starts
modifying the Emacs code that governs minibuffer
behavior, we get misguided, overly limiting behavior
imposed on Emacs, under the guise/excuse of "clean-up"
or in the name of "consistency".