You say that but it's actually a really easy problem to work around because the timing differences between an escape sequence and an escape key being pressed followed by any other character are vastly different. So you just look at the pause after the escape key to judge if it's an escape sequence or not (only needs to be a fraction of a second too).
In fact in the terminal stuff I've written in Go, escape sequences end up being picked up as one array even though the TTY is set to be unbuffered just because of the time the code takes to itterate through the STDIN read loop. So didn't even need to write any fancy timing logic for the terminal stuff I've written in Go.
Sure, in some rare edge cases you might have a situation when connecting to a remote TTY over a laggy network connection will cause the escape sequence to fail because of timing issues, but that's less of an issue these days and I think the terminal would be pretty unusable by that stage anyway.
> This is why so many curses-based terminal apps don't use escape to go back a level or close a window, even though GUI apps do it all the time. Too hard to make it work predictably.
Escape is used all the time in terminal apps though. Readline uses it when you have vim mode enabled (which means Bash also supports it), Vi obviously uses it heavily. Tmux, top, cfdisk all support escape. But most importantly ncurses stuff (eg dialog) does too.
So I think what you're talking about there is more of a UI design decision rather than terminal programs not being able to do it. Thinking back, I don't really recall escape being a common navigation idiom until it became popular on the web. Your typical 90s WIMP UI (eg Windows 9x, MacOS 7+) wasn't escape heavy either (or at least it wasn't a common way to navigate as I recall). Sure you'd use it on model dialogs (eg file->open) but really very little else. So terminal software - being much older, generally speaking - never had that convention either. In fact it wasn't even that common on the web until model dialogs became all the rage so people used to use the back button heavily (and hence why GUI file managers have forwards and backwards buttons in them - but that's a whole other tangent).
To be honest though, I much prefer the terminal approach anyway. Escaping out of screens feels very crude and the terminal approach for multiple "screens" of data was to use function keys or control sequences to precisely navigate from one screen to another. Or in the case of ncurses UIs, optionally using arrow keys to highlight the option you want. Personally I find the function key kind of workflow far easier to navigate than escaping stuff all the time but I guess it's what you're used to.
In any case, terminal apps don't need to wait for the next character to determine whether the user is pressing [esc] or [-->] (with the terminal emulator transmitting CSI+n+C). You just look at the timings instead.