You don't have to look hard to see that the Emacs maintainers aren't actively hostile to non-free OSes. Android is another good example. The Emacs manual states "it must be necessary to consider Android proprietary software from a practical standpoint." and yet a good amount of work went in to adding support for Android.

> If you're wondering what was controversial about the patch, GNU guidelines discourage adding features targeting non-free operating systems before it can be made available for GNU/Linux. While the patch could be easily reworked to expose the native capabilities available for each platform, there's plenty of room for interpretation as to whether a rework is considered enough to satisfy the guideline. Most of the discussion was centered around this topic. Once the thread was refocused around shaping the patch, I received super constructive feedback and the patch was indeed reworked to cater for different platforms. We also agreed to rename the feature from "share" to "send". To my surprise, even RMS also chimed in on the patch discussion. Achievement unlocked?!

Everything is recognized with the meta, because meta just sends an escape sequence followed by the key code for the other characters.

With all that said, there are thousands of reasons it could be working for you "it's just software" so anything can be programmed, but I'm not aware of say a terminal spec that supports more control codes. Usually when this works it's because the user has implemented one of the many workarounds available online (e.g., change the terminal emulator to send a different key code, and change Emacs to use that key code for the command). It's also possible the terminal emulator you're using has custom support built-in specially for Emacs.

I could fix this myself if I wanted to, but I've just found it's better for my sanity to work with terminal emulators as a clear spec (which includes only the limited set of control character codes) rather than work against that. For an example of how much work this can be to maintain, this is fixing all the discrepancies I've found in Alacritty where it doesn't send the correct key code by default https://github.com/robenkleene/Dotfiles/blob/4d06e9855465c00... I mainly did that to make terminal Emacs usable in Alacritty.

With all that said, if you have another terminal emulator handy, I'd be super curious if it works with that one as well.

And I restart mine every 2-3 days, so it doesn't have that much time to get slowed down.

The model of "slurp some events from a queue-like thing, throw some drawing at another queue-like thing, then wait for another event" is precisely what [NSApplication run] already implements. Per Apple

>A Cocoa application is event driven: It fetches an event from the queue, dispatches it to an appropriate object, and, after the event is handled, fetches the next event. With some exceptions (such as modal event loops) an application continues in this pattern until the user quits it.