"Input.config action on an editor-reserved key silently never fires in Play"

You bind a game action to an F-key (e.g. F1 for help, F3 for telemetry) in your Input.config. In-editor Play, the action never fires — no error, no log, the key press is silently swallowed.

The editor/host captures certain keys before they reach Input.config game actions. The confirmed reserved set (grows across builds):

• F3 / F7 / F8 are ShortcutType.Window editor shortcuts (toggle-fullscreen, pause, eject).
• F1 / F2 / Escape are also host-stolen in practice — they had zero [Shortcut] hits in a tools grep of engine 26.07.08e, so the capture map extends beyond the [Shortcut]-annotated set. Treat the [Shortcut] grep as a lower bound, not the full list.

There is no error or warning when a game input binding collides with a reserved key — it simply never arrives.

Bind game/UI hotkeys to plain letters instead of F-keys:

// Input.config example — safe bindings
Help        I
WorldMap    M
HideHud     H
Telemetry   F4    // F4 still reaches Play as of 26.07

For Escape (close menus, back navigation), use Input.EscapePressed — it's a real get/set property you can consume:

if (Input.EscapePressed)
{
    Input.EscapePressed = false; // consume it
    CloseMenu();
}

Do not bind Escape as an Input.config action. Verify every new binding in a real in-editor Play session — the reserved set can expand between engine builds.

Plain letter keys have no editor shortcut registrations, so they pass through to the game input layer cleanly. Input.EscapePressed is a dedicated engine API that survives the host capture because the engine explicitly exposes it for game-side consumption, unlike Input.config bindings that compete with the shortcut system.