The terminal protocol is broken in fairly fundamental ways (see: How do I get an event for <shift> key up/down by itself? How do I distinguish Esc by itself from Esc combined with something else)
> How do I get an event for <shift> key up/down by itself? How do I distinguish Esc by itself from Esc combined with something els
How do I drive a screw with a hammer? Badly. It doesn't make hammer a bad tool though.
Terminals are a simple tool. The inputs and outputs are lines of text. If your application doesn't fit that model and needs keypress events then terminal is simply the wrong tool for the job.
As I said, terminals are best suited for command line applications; lines of text in, lines of text out. Something that would work on classic ASR-33 or ADM-3A.
Dialog boxes, menus, and views are concepts that are more fitted to GUIs. And as such the right tool these days would be Wayland. For example, you get native keyboard scancode events and XKB keymaps, allowing far better input handling capabilities than any layering of hacks on top ANSI escape codes ever can.
The whole point of terminals is that they are simple, text based, and as such interoperable and standardized. ANSI escape code extensions are decidedly not text nor simple, and often very non-interoperable to varying degrees. As such they are pretty antithetical to the whole idea of terminals.
Perhaps we need a better example? Detecting "esc" is simple: it is its own key code (ASCII 27.) Detecting "esc" and another key is more difficult because it is not a modifier, like shift or control, so you'll have to do it yourself.
I think the issue is that ESC is also a prefix for other keys. Which leads to the question: is this just an escape or is this a prefix of e.g. a cursor key? This can only be answered by timing.
As far as standards go it is a fairly clean and easy to implement one. (That is the reason for its enduring popularity.)
Source: wrote a terminal emulator once. Turned out to be not that difficult. We just need to agree on an xterm-compatible subset of functionality and throw away the rest, which nobody ever uses anyways.
Your complaints are just aesthetic complaints, the terminal isn't supposed to be a universal GUI toolkit.
Yes, let's take dozens of terminal emulator projects out of maintenance mode so app devs can individually and capriciously overload my shift and escape keys, because modern.
And yet because of the *nix OSs being widely available it has even displaced superior models e.g. the Windows character cell model [0] is arguably a better fit for modern terminals yet new development goes to compatibility with "cross platform" inband signaling and escape sequences.
The terminal protocol is broken in fairly fundamental ways (see: How do I get an event for <shift> key up/down by itself? How do I distinguish Esc by itself from Esc combined with something else)
A lot of modern things have adopted the Kitty extensions in order to solve this: See: https://sw.kovidgoyal.net/kitty/keyboard-protocol/