The pair of sending and queueing deserves particular attention. An ordinary send starts work immediately, while queueing defers the message until the current step ends - different actions with different consequences for the trajectory, and telling them apart at the level of fingers rather than reasoning is useful. Accepting all changes and rejecting all differ in the same way: the two operations sit next to each other, differ by one key and cost very differently, because one of them destroys the result of the work entirely.

The same combination often means different things. The command key with K opens a pointed edit in the editor and the prompt bar in the terminal; the command key with return sends a message, accepts the suggested changes or runs the generated command. There is no contradiction here: the combination is addressed to whichever surface currently holds focus, and focus is the missing argument. So the question of what this combination does is incomplete without a second one: where is the cursor.

The practical problem with shortcuts is almost always the same: interception. The terminal, the shell, the window manager, an editor extension - each layer can take a combination for itself, and it simply never reaches the tool. From the outside that looks like a broken feature, although the feature is intact and can be invoked from a menu. The right reaction is to open the shortcut settings and see what is assigned rather than to hunt for a defect in the product.

Telling the two symptoms apart is not hard, and it saves time. If nothing happens at all, somebody higher up the chain took the combination, and the place to investigate is the system rather than the editor. If something happens but not what you expected, focus was in another surface, and the culprit is the cursor rather than the binding. From the same place follows the limit of sensible memorizing: a shortcut pays off when the action repeats dozens of times a day. Anything done once a week is cheaper to open through the command palette than to keep in memory.

There is also a flip side to the freedom of remapping. Having rewritten half the shortcuts to suit yourself, you get an environment convenient only to you: helping a colleague turns into a quest, and any instruction stops matching reality. A sensible compromise is to change a handful rather than dozens, and to record the changes where the environment's description lives, so that a new person on the project sees the deviations from the standard layout at once.

The engineering conclusion is simple: shortcuts are an interface to speed rather than to capabilities. Everything done by a shortcut can also be done through a menu; the value is that your hands stop distracting your head. So you learn the few frequently used ones and leave the rest to the reference, which is consulted without embarrassment.

The typical failures are predictable. Treating an intercepted shortcut as a broken feature. Pressing a combination without checking where focus currently is. Carrying over someone else's scheme whole and losing compatibility with the documentation. Not telling sending from queueing in long work. And memorizing the full list instead of ten working shortcuts.