bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Eli Zaretskii <eliz@gnu.org>]

> From: Len Trigg <lenbok@gmail.com>
> Date: Sat, 28 Dec 2024 07:11:35 +1300
> 
> On Sat, 28 Dec 2024 at 02:02, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  > From: Gerd Möllmann <gerd.moellmann@gmail.com>
>  > Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
>  > Date: Fri, 27 Dec 2024 13:47:09 +0100
>  > 
>  > Eli Zaretskii <eliz@gnu.org> writes:
>  > 
>  > > Then why is this a bug?
>  > >
>  > > When a frame is in a minibuffer, it means Emacs asks the user about
>  > > something, and in that situation, the user must respond to the prompt,
>  > > or exit the minibuffer in some other way.  That's normal in my book.
>  > > What am I missing?
>  > 
>  > Emacs doesn't say anything.
> 
>  It does: on the frame where you are in the minibuffer.
> 
> Hmmm, the repro scenario I gave doesn't involve either emacs client being still in the minibuffer AFAIK - the
> "working" client is just in a regular buffer (e.g. having been chosen via C-x b and selected), and the "hung"
> client is, well, hung.

Maybe you switched out of the minibuffer window, leaving the
minibuffer active?  In which case switching back to the mini-window
and exiting the minibuffer prompt (with RET or C-g or some other way)
should "unhang" the other client.  Is this indeed so?