I think we really need a new protocol for apps to use when interacting with terminals, which is richer than sending escape sequences.

It could just be the path to a Unix domain socket in an environment variable, where that socket speaks some kind of RPC protocol

Like [0] that Windows has for its console? This API has just recently finally lost to UNIX's in-line signaling, because the in-band controls can be proxied through almost anything, including literal serial line with two RX-TX wires and a common ground; the downside, of course, is that you have to build "out-of-line" signalling on your own.

If getting the current cursor position in the terminal were as easy (and as fast) as calling GetConsoleScreenBufferInfo, instead of sending "\e[6n" to the terminal and then reading input from it and looking for "\e[(\d+);(\d+)R" inside and then somehow unreading the input before that device report, yeah, that'd be nice and would allow solving a lot of problems with mere brute force. Sadly, it is not, and so most reimplementations of e.g. readline/linenoise functionality in shells and prompts (Erlang's shell went through 2 internal reimplementations just in my time using it, for example) are flying blind, hoping that their implementation of wcwidth(3) matches the terminal's one.

[0] https://learn.microsoft.com/en-us/windows/console/console-fu...