Interesting, I hadn't seen CSI-u mode before. It looks like it's a toggle for the whole profile though, rather than something the CLI tool can opt in to, which means it will break any tools that expect existing keys like C-M-e to be ^[^E, and that seems rather unfortunate.

It looks like kitty actually has a means of requesting this stuff dynamically with CSI = flags ; mode u (and a push/pop stack). It also says it will use CSI-u mode automatically for keys that don't have a "legacy" escape, but I didn't see this before because stuff like C-M-3 does not in fact echo as CSI-u but instead that inputs as just 3 instead of CSI 5 1 ; 7 u. Even using Kitty's "progressive enhancement" mode to request disambiguation of escape codes leaves C-M-3 broken which is rather confusing. Versus iTerm where its profile-wide CSI-u mode toggle does report C-M-3 correctly.

In any case, Terminal.app doesn't support this, and I'm not sure what else does. Looking at Alacritty right now, I don't see any direct support for this, the closest I've found is some issue comments suggesting setting up custom key bindings to simulate it (which I guess means defining every single combination of modifiers for every single keyboard key?).

As for Command, yes, it should be for actions _to_ my terminal. But for GUI apps they go to that app, and so replacing GUIs with TUIs means losing the ability to use Command for this sort of thing. For example, in MacVim I can press ⌘N to open a new MacVim window. In vim I can't, because that just opens a new Terminal window. Or ⌘A to select all, which doesn't even have an equivalent CLI key shortcut (e.g. in Vim I'd have to type something like ggv<C-End>, exiting insert mode first if necessary).

And of course proper usability of the terminal typically requires binding Alt to Meta, but doing that means losing the ability to type non-ASCII chars on macOS. This is another thing that GUIs don't have to worry about.

> As for Command, yes, it should be for actions _to_ my terminal. But for GUI apps they go to that app,

I don't see a way to split the difference between ⌘N for a new terminal window and ⌘N for a new application window. It has to do one of those things because it can't to two, and speaking personally, I want it to open the new terminal window. It's a tradeoff.

CSIu mode is new, it's pretty well supported though.

> And of course proper usability of the terminal typically requires binding Alt to Meta, but doing that means losing the ability to type non-ASCII chars on macOS. This is another thing that GUIs don't have to worry about.

This doesn't happen to be true though, right Option can be the compose key and left Option can be Meta/Alt aka prepend-with-Escape. I also use Karabiner to set pressing left Alt to send Escape for even more faithful terminal fidelity, but that's optional. Having both Compose and Alt as right and left Option is perfectly straightforward, and I suggest it, because much like with Command, it does have to do one or the other, but this time, we have two keys.

It's probably possible to split the left and right command keys but again, personally, I don't want the terminal app to see my command keys and am comfortable with the mere six(!) combinations of modifier + key I can send without it.

> I don't see a way to split the difference between ⌘N for a new terminal window and ⌘N for a new application window. It has to do one of those things because it can't to two, and speaking personally, I want it to open the new terminal window. It's a tradeoff.

Right. I'm not saying CLI tools should be able to get command-keys, I'm saying using a TUI instead of a GUI means you cannot use command-keys. It's a notable limitation inherent to TUIs, and it's one I'm talking about since the context here is "the terminal is the most portable GUI platform available".

> Having both Compose and Alt as right and left Option is perfectly straightforward, and I suggest it, because much like with Command, it does have to do one or the other, but this time, we have two keys.

I like that this is an option in some terminal emulators. Unfortunately it's not an option in Terminal.app, and for me personally I'm using right-option for something else system-wide (though I may have chosen differently if Terminal.app offered this).