Escape is traditionally distinguished from an escape code by a timeout: if no more characters arrive within some small number of milliseconds, then it was the user pressing escape and not the start of an escape sequence. No new solution to that “problem” is really necessary.

Likewise, programs don’t really need to know if the terminal supports an extended set of key combinations, because they can just react to them if they arrive. If they don’t arrive, then either the terminal doesn’t support that feature or the user didn’t type that key combination; either way the program needs to do nothing.

As for modifiers, good look finding a keyboard that supports more than the basic four. No need for xterm to go out on a limb and support something you can’t use anyway.

And who cares about num lock and caps lock? I’ve never seen any program care what state they were in. Well, GDM does warn you if capslock is on during a password prompt, but that is very niche.

Terminals have never operated on scan codes, so keyboard layouts are irrelevant. The application doesn’t really care what button you pressed to get a Q, just that you typed a Q.

Likewise there has never been support for key release events on terminals. I suppose it’s useful for games, but in most other situations the user will have autorepeat configured and that will handle it.

Why should xterm go out on a limb and invent a scheme that tries to cover every possible future need, even needs that are not in evidence? Better to implement something simpler that just covers what is actually needed. It can always be extended later.