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

[Karl Fogel]

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