??? Passing to proper owner.

Agreed. Improving test coverage for this piece of code are important. However,
it's even more important to fix the existing known bugs in this and other areas.
This set of tests is not a priority for 5.0. ->P3

If you want to help out and write a few tests, go ahead. Your contribution will
be appreciated. 

Too late for NB5.0, please reevaluate.

Jesse has just rewritten the code as part of issue 152576 and I am sure he added some tests.

I indeed added unit tests for NbKeymap itself, including for its handling of multi-key shortcuts. Unfortunately the real
behavior of this feature is spread out across:

1. NbKeymap
2. ShortcutAndMenuKeyEventProcessor
3. some stuff in the editor I only partly understand, e.g. NbEditorKit
4. Swing itself

While the interfaces to Swing are documented (if not in great detail), the interfaces among the other three components
are not documented at all (in fact reflection is used in one case), so in my NbKeymap unit tests I could only guess at
what the "correct" behavior is. For example, with Emacs bindings active, should calling getAction() on C-X immediately
shift the context register and return null? Return an Action which when actionPerformed is called shift the context?
Immediately shift the context and return a no-op Action? In the latter two cases, should this Action be marked enabled
or not? Should certain incorrect sequences cause the IDE to beep? Which "special" key events should be ignored, so that
e.g. Alt-F continues to post the File menu (except in Emacs mode where this is bound to forward-word)?

AFAIK there are no automated integration tests which prove that sending particular KeyEvent's at particular times to
particular Component's has the desired result, regardless of the implementation of certain code units. I tried to
confirm at least reasonable behavior by manual experimentation using different keymaps, on actions with single or
multi-key bindings, defined either globally (C-X C-S for Save in Emacs) or in the editor (C-U U for Uppercase in NetBeans).

The new implementation of NbKeymap.getAction() is at least shorter and has simpler control flow than the old, so it
ought to be easier to fix any issues in the future.

AFAIK there are two Keymap impls: NbKeymap and o.n.editor.MultiKeymap both trying to handle multi-key shortcuts for a different sets of actions ("system" 
and editor ones). Let's assume there is a "system" action bound e.g. to "Ctrl+J then Ctrl+K" and an editor's action bound e.g. to "Ctrl+J then Ctrl+L". When 
pressing "Ctrl+J" then both keymaps must shift their internal "context" in order to properly respond to an ongoing shortcut. Once a valid action is found in one 
of the keymaps then the other one must be called to explicitly reset its context (otherwise it would stay in a ctrl-j-just-pressed context).

Actually I would be glad if we could get rid of the reflection and make the things cleaner.
1) It's probably unrealistic at the moment to use a single mechanism for resolving actions both in editor (mime-type specific stuff etc.) and rest of the IDE.
2) Generally I would prefer using InputMap+ActionMap instead of Keymap.

I would like ShortcutAndMenuKeyEventProcessor to consult ActionMap of the focused component and retrieve
   Action contextResetAction = actionMap.get("context-reset-action");
3) Once SAMKEP would resolve action through NbKeymap successfully it would also reset context of InputMap of the focused component by issuing 
contextResetAction.actionPerformed().
4) If necessary context-setting actions (e.g. an action returned for Ctrl+J in example above) could be specially marked e.g. by
  Boolean.TRUE.equals(action.getValue("is-context-set-action"));

I like the idea of actionMap.get("context-reset-action") - cleaner than reflection.

What you propose sounds reasonable but I'm probably not qualified to review it.