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.
I used to search for a couple of lines of code in the getty.c program or its ancestors, which permitted ALL CAPS LOGIN because teletypes and early VDU terminals included models without a shift function. It made me ask myself how the password check was able to function (and how strong the crypt function was) if the case wasn't important.
They were removed from (at least) FreeBSD sometime in the 2.x series I believe.
xcase Echoes uppercase characters on input, and displays uppercase characters on output with a preceding \ (backslash).
iuclc Maps uppercase alphabetic characters to lowercase.
olcuc Maps lowercase alphabetic characters to uppercase on output.
Solaris (Illumos) source code is consistent with this.
So for an upper-case only keyboard, uppercase letters are lowercase. To type an uppercase letter, precede it with a \. The tty layer handles the conversion so programs don't know or care what you're actually typing -- they just read (and write) normal upper and lower case characters.
