Advanced keyboard input broken on Windows (Backspace / Shift / Ctrl+digit) despite kitty protocol negotiated #82

Summary

On Windows (both Windows Terminal and WezTerm), several keys don't reach the app correctly:

• Backspace does nothing
• Shift+letter doesn't capitalise
• Ctrl+0 (and Ctrl+digit generally) is never received — see Ctrl+0 no longer focuses the Explorer when the editor has focus #81

This affects the main editor body, not just dialogs, so it is global and independent of any feature PR (e.g. #80 reproduces it in the editor). It works correctly on macOS.

Key finding: kitty is already negotiated

F12 Diagnostics on Windows shows:

• Driver: ansi
• Kitty kb: Yes (DisambiguateEscapeCodes, ReportEventTypes, ReportAlternateKeys, ReportAllKeysAsEscapeCodes, ReportAssociatedText)
• Last key after a keypress showed a modifier-only event: Name = Alt, Base = 0x00000000, Rune = —

So this is not "the kitty keyboard protocol isn't enabled" — it is fully negotiated with the complete flag set. The problem is that TG's ansi driver on Windows isn't correctly turning the richly-reported kitty key events into key presses. The modifier-only Last key suggests mishandling of ReportEventTypes (press/release/repeat) and/or ReportAllKeysAsEscapeCodes, so editing and modifier-bearing keys get dropped or misread.

We are on Terminal.Gui 2.1.0.

Why macOS works

The macOS terminal-integration work negotiates kitty and scopes app key tables: iTerm2 dynamic profile (#65) and WezTerm lua module + enable_kitty_keyboard = true (#69). On macOS the same ansi + kitty path decodes keys correctly; on Windows the same negotiation is present but decoding fails — pointing at a Windows-specific ansi-driver issue, not a missing-integration issue.

Investigation / candidate fixes

1. Upgrade Terminal.Gui 2.1.0 → 2.2.x (currently in RC). 2.2 ships kitty-protocol support and Windows keyboard fixes (Add support for the Kitty Keyboard Protocol tui-cs/Terminal.Gui#4809, release notes). Re-test first — this may resolve it outright.
2. A/B the driver on Windows. TG exposes selectable drivers via Application.Init(driverName: …) (we pass null = auto, which resolves to ansi). Try forcing v2win (Win32 Console API — reads Backspace/Shift/Ctrl+digit natively, bypassing escape-sequence/kitty parsing) vs v2net/ansi. Add a driver override (env var or CLI flag) so we can test without recompiling. (cf. Driver "v2win" broken in conhost tui-cs/Terminal.Gui#4004 "v2win broken in conhost".)
3. If the ansi driver is the culprit, consider requesting a reduced kitty flag set (e.g. without ReportEventTypes/ReportAllKeysAsEscapeCodes) or file upstream with the diagnostic above.
4. Windows terminal-integration parity (analog to Move terminal-integration setup into TuiCode (iTerm2) #65/WezTerm: ship Lua module + activation OSC for app-scoped shortcuts #69), once decoding works: ungate WezTermIntegration from IsMacOS (WezTerm supports enable_kitty_keyboard cross-platform), and add a Windows Terminal fragment/guidance (kitty supported in WT Preview 1.25+).

References

• Ctrl+0 no longer focuses the Explorer when the editor has focus #81 — Ctrl+0 not received on Windows (same family)
• Add support for the Kitty Keyboard Protocol tui-cs/Terminal.Gui#4809 — Add support for the Kitty Keyboard Protocol
• Driver "v2win" broken in conhost tui-cs/Terminal.Gui#4004 — Driver "v2win" broken in conhost
• Terminal.Gui releases — 2.2.0-rc series (kitty + Windows keyboard fixes)
• Windows Terminal kitty protocol support landed in Preview 1.25