That's a frame made by

(defun my-make-child ()
  (interactive)
  (make-frame `((parent-frame . ,(selected-frame))
		(background-color . "gray10")
		(foreground-color . "white")
		(top . 15)
		(left . 40)
		(width . 80)
		(height . 25))))

> Cursor handling on ttys is an arcane art as I recently noticed.

Not only cursor handling :-).

I think I've meanwhile spent umpfteen times more time with the whole
frame handling than the redisplay part. It's a maze.

> I have no idea how it works. Does the echo area work normally when you
> are in the child frame in the sense that text does not appear in the
> normal minibuffer frame too?

Yes, I think the child behaves pretty much as if it were a normal
non-child frame, only that it is displayed on top of the parent.

(We display the cursor at the position that the selected window tells
us, while writing to the terminal. Which was how it also worked on GUIs
pre-21, when each window got a cursor. I had of course to change that
slightly because the selected window can be in a child, and we have to
take the child frame top/left into account.)

> Does the cursor show up as expected in normal
> text areas when you switch between parent and child frame?

I think so, yes. The selected window determines where the cursor is
displayed. If that is on the child frame, the cursor appears in the
child frame, if I select a window in the parent frame, it's there.

> If so, I see no way around tracing cursor movement during a dialogue
> and look where the cursor_to commands come from. Also the fact that
> the prompt appears in both minibuffer windows is obviously fishy but
> IMHO it's a redisplay issue as well.

Hm, if the window on the posframe isn't selected, that could explain it,
maybe. That could be an idea, but why wouldn't it be selected? Questions
about questions.

Thanks! Good that we spoke about that.

>
> Maybe as a first step I would not give child frames on ttys their own
> minibuffer windows.  Let them use the minibuffer window of the normal
> frame that hosts them and you're done (making sure that a child frame
> never obscures a minibuffer window).  

That's what current happening, in a way. And I at least find it
confusing because the music plays in the posframe, so to say,
user-interface-wise, not in the minibuffer at the bottom of the frame.

> User input always goes to the same terminal window so there are no
> focusing or redirecting issues you have to resolve. And displaying
> dialogues from minibuffer-less child frames should be handled
> correctly anyway.

Tja well the problem is that I don't want to mess with posframe and
packages using it. I'd rather have something working as much as possible
as on GUIs.

(It does pretty much that, including Corfu now, except for the remaining
problems, and the minibuffer stuff is not the only one. But none of that
in redisolay but in differences in frame handling. Frustrating.)