I'm not sure that this is possible. For example, some (most?) accelerators, like Alt+Tab, trigger on non-modifier key-down. When we receive a Tab key-down event, there's no way of knowing if we should treat that as a regular Tab event or if we need to wait for Alt to also be pressed.

I think that the correct behavior here is that all of an accelerator's modifier keys may be pressed in any order, but the accelerator is completed as soon as its non-modifier key is pressed.

In the example you gave, either Ctrl+Shift+v or Shift+Ctrl+v should work. I don't think that the Linux behavior is particularly desirable, though. (Linux is also fairly lacking in platform conventions compared to Windows and macOS, so I wouldn't use it as a model of "correct" behavior.)

I think that the actual issue, which is also the reason for issue 789283, is that we have a weird Alt+Search accelerator that essentially consists only of modifier keys. Search is weird in general, since it also has a function when it's pressed on its own (which I accidentally trigger all the time). I don't know that I have any good answers here apart from trying harder to clearly classify keys as either being modifiers or not being modifiers.

I checked the behavior on Mac. "shift+v+cmd" could work on paste but "tab+cmd" cannot work (only "cmd+tab" would work for cycling opened windows). I don't have access to Windows right now.

Besides trying to find a "correct" behavior on other platforms, I am trying to find the definitions of "keyboard shortcut" and "modifier key". This is something from wiki [1]: 

"For simultaneous keyboard shortcuts, one usually first holds down the modifier key(s), then quickly presses and releases the regular (non-modifier) key, and finally releases the modifier key(s). This distinction is important, as trying to press all the keys simultaneously will frequently either miss some of the modifier keys, or cause unwanted auto-repeat."

I agree we definitely need the behavior that "all of an accelerator's modifier keys may be pressed in any order, but the accelerator is completed as soon as its non-modifier key is pressed." And that is what-it-is on Chrome OS right now.

For Search and Search+Alt alone, when they worked as functional keys, they are triggered on release when not consumed on pressed as modifiers. That is why "alt+arrow+search" would trigger toggling caps lock.

If we expect users to press all modifiers first and then press non-modifier key to operate shortcut, then this bug could be a WontFix. However, could we expect this assumption?

[1] https://en.wikipedia.org/wiki/Keyboard_shortcut

Assigned to UI/PM for decision. I think the best way to do this would
(1) check windows behavior
(2) launch the "search+alt+arrow keys" moving window between displays feature to observe whether we have user complains.

warx@, when you said: 

""alt+arrow+search" would trigger toggling caps lock"

In what order are the keys released? Can you please investigate why this code [1] is not working?

[1]: https://cs.chromium.org/chromium/src/ash/accelerators/accelerator_controller.cc?q=CanHandleToggleCapsLock&sq=package:chromium&l=762-787

I think this is a wontfix. 

Re #3, it happens on this condition:
the pressing order is not search+alt+arrow or alt+search+arrow, the releasing order is 
not-first-releasing-arrow-key.

Note: (p) indicates pressed, (r) indicates released
For example, alt (p) -> arrow (p) -> search (p) -> search (r) -> alt (r) -> arrow (r).

The problem starts from AcceleratorFilter::OnKeyEvent [1]:
alt (p): we have accelerator key_code: ui::VKEY_MENU
alt (p) -> arrow_right (p): we have accelerator key_code: ui::VKEY_RIGHT with modifier Alt
alt (p) -> arrow_right (p) -> search (p): we have accelerator key_code: ui::VKEY_LWIN. It looks like key_code arrow_right info is lost.

Thus the logic in your link will do exactly the same as alt (p) -> search (p).

[1] https://cs.chromium.org/chromium/src/ui/wm/core/accelerator_filter.cc?q=accelerator_filter&sq=package:chromium&l=42

I would try something like: let ash::AcceleratorController cache a member to know whether arrow keys are pressed/released.

Re 4: I am also inclined to WontFix after some investigation.