https://vt100.net/emu/dec_ansi_parser
Just look how many paths lead to the "csi ignore" state.
Do you have a specific physical terminal that's even older than the VT100 that you're worried about?
And it isn't just real terminals. Several terminal emulators are bad at handling syntactically valid but unknown to the emulator control strings. There are several whose authors hadn't read ECMA-35 and ECMA-48, and based their programs on samizdat lists of control sequences circulating years ago, without realizing that there was a full consistent syntax underlying them. Unrecognized control sequences are sometimes just printed as text, or worse.
Indeed, OSC itself is notorious for being such a case, where for a time some emulators expected BEL instead of ST as the string terminator.
> Correctness – if you were to feed this parser a stream of characters that is random or deliberately pathological, it is claimed that this parser will exhibit the same visible behaviour as any one of DEC’s 8-bit ANSI-compatible terminals, from VT220 to VT525. A VT100-series parser would be simpler still, as the VT100 only supports 7-bit characters.
To your other point, if we're not talking about replacing expensive hardware anymore, but just obscure buggy software--shouldn't they fix the bugs instead of the entire industry halting all forward progress for the rest of time?
We've done this before. Hyperlinks are a pretty recent introduction, and are widespread by now. So either these buggy terminal emulators were already fixed as hyperlink usage became widespread, or they're unmaintained and already broken by hyperlinks. Either way, new standards won't make the situation any worse.
terminfo's problem is that it is really difficult to make changes that extend or do not fit the original paradigm, not least because the actual database format does things like have a fixed set of implicitly-named boolean capabilities, with any additional capabilities having to be named 'extensions'.
* https://github.com/mauke/unibilium/blob/master/secret/termin...
But other problems include terminfo's model of how things work, such as function keys for example, not really matching how they actually work in terminals and terminal emulators. For function keys, for example, DEC terminals allowed modifier state to be sent in parameters to DECFNK. terminfo's design had no concept of this.
Nushell already kind of has this philosophy - there is a separation between the actually scripting of tools (prints out structured json), and the visualization back to the user if it's a terminal. On top of this, you could say, have some awareness of, "If I know I'm the remote, I can pass a json list to the userdirectly and have them render client-side, rather than pretend to be a terminal".
It may be inefficient for some cases, but then you could actually say, execute the vision of mosh.
The terminal, in the abstract, is one of the best abstractions ever. The implementation is tied down to 1980s tech.
You could always spin up a "normal" terminal if you're ssh'd into some remote server to do sysadmin stuff. IMO you shouldn't be installing personal configs on there anyways (maybe allow a copy pasted .bashrc and .tmux.conf)
Another thing you could do - neovim already has neovide, you could make this native, right? You would maybe write an adapter for neovim on the remote (again, all of this is in vresion control + nix; this is how I use dotfiles; and at work I'm doing nothing fancy since I don't have control over host, it's just temrinal integration) - if I type "nvim" in the "shell" application, it actually opens up its msgpack GUI protocol.
Maybe at some point you're just re-inventing emacs though.
I've also never really fully understood why terminfo seems to be a singular package, and not something like man pages where, e.g., each terminal drops in their respectively entry.