Function minibuffer_owns_caret 

pub fn minibuffer_owns_caret(modal: ModalState) -> bool

Does a minibuffer own the caret in this modal state?

True for the three buffer-backed readline surfaces — the : command line, the /·? search line and Effect::OpenPrompt’s prompt. Each draws its own caret at its own buffer’s cursor, so every OTHER surface must leave the caret alone while one is open.

Renderer-neutral because both peers got this wrong the same way. The TUI drives one hardware caret, so two surfaces placing it means the last writer wins; GPUI paints carets as elements, so two surfaces mean two carets. Different symptoms, one question — and the pane path already asked it locally (prompt_owns_cursor) while the popup path did not ask it at all. Reported in use: with a popup focused, / left the caret sitting in the popup and merely changed its shape to a Bar, so a read-only popup looked like it had entered Insert.

Note it includes Prompt, which the TUI’s local copy omitted — the prompt line draws its own caret exactly as the other two do.