In the spirit of keeping individual bugs focused on their reported issue, I'm opening this RFE to have a documented discussion.  We can immediately turn around and close it as NOTABUG or WONTFIX or whatever as appropriate.

The question is this:  TODAY, what exactly is the role of the "alternative" keybindings?

Looking at the history, previous bugs, comments in code, etc., it seems that the alternative keybindings were necessary for the following reasons:

1. Impact of NumLock (KP_Page_Down vs. KP_3)
2. Sun keys in Solaris (press F11 and we get SunF36)

A while back, some keycode/keysym-related changes were made that I admittedly haven't taken the time to fully grok.  But they may be relevant in terms of solving issues such as the above. :-) In addition:

In the past few months, a change to AT-SPI seems to have taken care of some NumLock issues:  I removed all of the alternative bindings via the Preferences dialog and tried flat review both with NumLock on and with it off.  All of the flat review commands worked, both in Solaris and in Ubuntu.  Mind you, I don't own a Sun keyboard, so perhaps things are different there...  But if they are not, is there still a NumLock-related reason we need to keep alternative keybindings around?

Regarding Sun keys, I noticed something interesting: If you get into Learn Mode in Solaris and press F11, Orca speaks "F11" but it brailles "SunF36".  Looking at orca.py, SunF36 is the event string associated with the keyboardEvent, but we're able to derive F11 from keynames.getKeyName().  Therefore, should our keybindings code do something similar to capture (and recognize) "F11" instead of "SunF36"?  And, if so, again:  Is there a Sun key/Solaris-related reason we need to keep alternative keybindings around?

We also have bug #440490 to separate out keybindings with multiple clicks for the purpose of documentation and potential re-definition.  If we implement that RFE (which I think is worth doing), as Will indicated we will need a click count column -- I would argue two, one for the main binding and one for the alternative binding, unless we assume that if one wishes to double-click the main binding they would also want to double-click the alternative binding.... Either way the keybinding pane in the Preferences dialog is starting to get rather large and complex.

I can see a couple of reasons for wanting to preserve the alternative bindings beyond the NumLock and Sun Key/Solaris issues:

1. Maybe users want to have two bindings for the same command:  Say, read the title bar by pressing Orca+T or Orca+KP_Enter as the spirit moves them.

2. Facilitate the definition of keybindings for different locales (see bug #436926).

To be honest, I personally don't see many users wanting two bindings for the same command unless they have a locale-related issue.  As for the locale-related issue, I admittedly don't understand it.  Having read the original bug report, I set up Ubuntu so that I could switch between the US keyboard layout and the Russian keyboard layout.  When using the Russian keyboard layout, Cyrillic characters appeared when I typed; however, Orca acted as if I were still using the U.S. keyboard layout.  As a result, I could type Cyrillic characters while still using my existing keybindings and not having to switch layouts as (I believe) the user reports having to do.  Nonetheless, if I wanted entirely different keybindings based on the locale being used, is *that* a good role for alternative keybindings?  OR is that the role of some clever localization magic of which I am unaware?

Phew!  That's all of my thoughts on this at the moment.  I'm curious as to what others think.  Thanks!!