Should the Mac command key map to InputEvent.CTRL_MASK?

Having to use control instead of command causes problems for VoiceOver users, e.g. for the first two sets of commands.
- control option: First Level VO Commands.
- control option shift: Second Level VO Commands
- control option command: Third Level VO Commands
- control option shift command: Fourth Level VO Commands

If command mapped to InputEvent.CTRL_MASK that would eliminate the conflict. Java apps could then use all of the following without conflicting with VO keys.
- command aKey
- command option aKey
- command shift aKey
- command option shift aKey

and use of the command key is consistent with the Mac shortcut standard.

Also, if "apple.laf.useScreenMenuBar" is off, control F2 moves focus to the menu bar. So even without VO there is that side effect when using a shortcut/accelerator of control (plus other optional modifiers) F2. If command was mapped to control that conflict would be removed.

I suspect that even if "apple.laf.useScreenMenuBar" was on, control F2 might move to the menu bar but at least visually I didn't see it, perhaps due to other interactions with that menu bar, interactions that would otherwise be happening on the Swing menu bar.