What you say about keyboards is true for PC keyboards, but was not always, historically, the case. Terminals always sent the ASCII code of the pressed key(s), and especially in early terminals, all CTRL really did was to mask off the highest bits of the transmitted code leaving a value between 0-31 -- the ASCII control range. That's why ^I is TAB and ^[ is escape.

If we implemented what you proposed, terminal emulators wouldn't be terminal emulators anymore -- they'd be some sort of generic input and output framework. While we're at it, why don't we include another API to take advantage of the high-color framebuffer displays most modern computers enjoy rather than just displaying a grid of fixed-width text characters. Oh look, we've just reinvented X11. Again (see: Wayland).

Or how about no, because it's yet another library dependency in what should be a straightforward terminal program, and the whole solution breaks when the program is talking to a real live terminal (as Linux programs can still actually do) because there is no "underlying key event" from a terminal. And if you are assuming an environment like X11 or Wayland, just write an X11 or Wayland program and be done with it. (Both vim and Emacs have taken this approach, and AFAIK support keybindings of the type you describe while running in graphical mode.)