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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: al@petrofsky.org, rudalics@gmx.at, 63967@debbugs.gnu.org
> Date: Fri, 09 Jun 2023 19:09:19 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > And if it happens with `read-buffer-to-switch` I can't see any reason
> > why it wouldn't happen for most/all other uses of the minibuffer.
> 
> It probably does, yes.

AFAICT, the clobbering of the selected window happens in
minibuffer_unwind:

  static void
  minibuffer_unwind (void)
  {
    struct frame *f;
    struct window *w;
    Lisp_Object window;
    Lisp_Object entry;

    if (NILP (exp_MB_frame)) return; /* "Can't happen." */
    f = XFRAME (exp_MB_frame);
    window = f->minibuffer_window;
    w = XWINDOW (window);
    if (FRAME_LIVE_P (f))
      {
	/* minibuf_window = sf->minibuffer_window; */
	if (!NILP (w->prev_buffers))
	  {
	    entry = Fcar (w->prev_buffers);
	    w->prev_buffers = Fcdr (w->prev_buffers);
	    set_window_buffer (window, Fcar (entry), 0, 0);
	    Fset_window_start (window, Fcar (Fcdr (entry)), Qnil);
	    Fset_window_point (window, Fcar (Fcdr (Fcdr (entry))));
	    /* set-window-configuration may/will have unselected the
	       mini-window as the selected window.  Restore it. */
	    Fset_frame_selected_window (exp_MB_frame, window, Qnil);  <<<<<<<<<
	  }
	else
	  set_window_buffer (window, nth_minibuffer (0), 0, 0);
      }
  }

And since minibuffer_unwind is called _after_
restore_window_configuration, it overwrites what the latter does.

Why minibuffer_unwind doesn't test some condition which would tell it
at all has to do something, I don't know.  It seems to think that the
frame exp_MB_frame is still live and that its "expired" minibuffer
needs to be replaced? why?  Is the logic inside read_minibuf_unwind
flawed in the case that enable_recursive_minibuffers is non-zero?