On macOS 26.5.2 (25F84), the built-in "Select the previous input source" shortcut (Control+Space) switches the input source and then reverts it roughly 100-500 ms later. The net effect is that the shortcut appears to do nothing. The trigger is the timing of the two key-up events, not their order. I reproduced this with synthetic events (CGEvent posted to .cghidEventTap), varying how long Space is held and the delay between the two key-up events. 15 trials per condition. "reverted" means the input source changed and then changed back, leaving the original source selected. Space hold Key release persisted reverted no response 30 ms simultaneous 14 1 0 60 ms simultaneous 7 8 0 100 ms simultaneous 3 11 1 150 ms simultaneous 1 14 0 200 ms simultaneous 0 15 0 250 ms simultaneous 0 15 0 300 ms simultaneous 2 12 1 600 ms simultaneous 1 13 1 60 ms 20 ms apart, Space first 15 0 0 60 ms 20 ms apart, Control first 15 0 0 300 ms 20 ms apart, Space first 15 0 0 300 ms 20 ms apart, Control first 15 0 0 "simultaneous" means the two key-up events are posted back to back with no delay between them, so they land in the same event batch. A 20 ms gap between the two key-up events makes it completely reliable: 60/60 trials across four conditions. Which key is released first makes no difference. A separate monitor process polling TISCopyCurrentKeyboardInputSource recorded two input source changes per failing trial - the switch, then a revert 104-588 ms later - and exactly one change per trial in the four 20 ms-gap conditions. Other things I checked: Not the input source machinery. Selecting the same two sources 25 times via TISSelectInputSource, with no keyboard involved, never reverted (0/25). The fault is in the hotkey path. Not key auto-repeat. Holding Control+Space does not cycle through input sources. No duplicate binding. AppleSymbolicHotKeys ID 60 is the only enabled system hotkey bound to keycode 49 with Control alone. Not specific to one IME. I see it with ABC and a third-party Japanese input method; Apple Community thread 256254361 reports the same behaviour with English and Russian, 16 "Me too", across multiple keyboards and applications. That reporter also confirms the Globe/Fn key is unaffected. In a week of normal use a background monitor recorded 733 input source changes, of which 6.5-13.4% were a switch immediately followed by a revert (the range depends on the reversal threshold used: 250 ms to 1000 ms). Real-world reversal intervals were 135-433 ms, median 247 ms - inside the range seen in the synthetic reproduction. One caveat on reproducibility: the 600 ms simultaneous-release condition varies between runs. An earlier run of the same matrix had it persisting 14/15 while the run above had it reverting 13/15. The 150-300 ms band failed in both runs. Filed as FBxxxxxxxxx with a self-contained reproducer (single Swift file, ~170 lines, needs Accessibility permission and two or more enabled keyboard input sources). Questions: Is the simultaneous-release behaviour intentional in any way, or is this simply a race in the hotkey handler? Is there a supported way for a user to make Control+Space reliable, short of moving to the Globe/Fn key or a third-party remapper? For anyone hitting this: does the 20 ms release gap also fix it on your machine? I would like to know whether the threshold is machine-dependent.