In most of those cases, because of the historical precedent, these libraries/runtimes don't even have a concept of "keyup" for their TTY-like abstraction, so adding this to them may entail a bit more work than it sounds—especially if, like the JVM, they have a static interface/protocol built in to specify the API of a "TTY-like object", which cannot be changed, since third-parties have compiled code against it and expect that code to remain ABI-compatible with new versions of the runtime.

No. You miss the point. I need to do nothing. I have no reason to do anything. Give me a reason and then we can discuss what I need to do. I need a rationale to do something, without rationale my work would be pointless and you might argue indefinitly that anything that I've done already is not enough.

"This", in that phrase, stands for the problem in the OP post title—"it being so hard to detect keyup event on Linux."

And "on Linux", in the OP post, is a shorthand for "in all the arbitrary applications that exist in the Linux userland, or that one might choose to write in the Linux userland." (You can tell that it has this meaning, because under the more literal meaning of "on Linux"—working within the Linux kernel itself—it is already quite easy to detect keyup events.)

Obviously, fixing the entire Linux userland is an unbounded amount of work. That is precisely why the other commenters above are saying that it cannot be done. Not "done" as in "worked upon", but "done" as in "finished."