Why does `read-multiple-choice' lock user into minbuffer?

[Karl Fogel <kfogel@red-bean.com>]

When I tried to send an email recently, I got prompted by `nsm-query-user' (in lisp/net/nsm.el), as the remote SMTP server I was sending through had rolled over its LetsEncrypt certificate during my Emacs session.

This caused me to get prompted with the expected array of choices:

  (a)lways        -> "Accept this certificate this session and for all future sessions"
  (s)ession only  -> "Accept this certificate this session only"
  (n)o            -> "Refuse to use this certificate, and close the connection"
  etc, etc

And while the minibuffer asked me for a response, a new "*Network Security Manager*" buffer was helpfully displayed in a new window.

I wanted to copy some text from that buffer, so I tried `C-x o' to get over there.  But that didn't work: point was locked into the minibuffer.  I tried clicking with my mouse in the other window, but that did not bring me to the window either.  And since `nsm-query-user' kills the "*Network Security Manager*" buffer after the user gives her answer, in the end I had no way to copy that text.  I couldn't do it while the buffer was being shown to me, and I also couldn't do it after I'd finished responding to `read-multiple-choice' -- because by the time control got back to me, the buffer I wanted no longer existed.

Now, a local solution to this problem would be to just not kill the buffer at the end of `nsm-query-user'.  (Actually, there are two buffers killed there, and I don't really see why we should kill either of them at the end -- `nsm-query-user' erases them when it needs to.)

But I'd like to understand the more general question too: why does `read-multiple-choice' lock the user into the minbuffer so strictly?

Its doc string doesn't say anything about this behavior, and other functions that prompt the user (e.g., `find-file') don't enforce minibuffer habitation the same way.

Best regards,
-Karl