gnome-terminal-2.2.1-3 does not work right with non-us keyboards. For example with ru keyboards. See http://bugs.xfree86.org/show_bug.cgi?id=508 for detailed description of the problem.
If vte is using XEvent directly it may not be ignoring bits 13 and 14 (the Xkb group identifier)
My guess is rather that VTE is translating Control+A to ^A, but not translating Control+(russian character at that position) to ^A. You'd have to figure out what behavior you wanted, then you could use GdkKeymap to implement it. (You could also using GtkBinding to establish bindings for Control+@ => Control+Z - using a single binding signal with a callback parameter, and then let GTK+ handle the fuzzy group matching for you.)
No, trere is no Ctl-russian character sent to VTE. VTE receives standard Ctl-A, but xkb modifier has an extra bit set (second keyboard). VTE supposed to ignore this bit (X programs such as xtem/mozilla/gedit/... do ignore it) but VTE does not ignore this bit. This is VTE bug. Check http://bugs.xfree86.org/show_bug.cgi?id=508 foe exact records of X events. It is clear from there what bit is not ignored.
This is the difference in events in US and RU modes. state 0x4, keycode 38 (keysym 0x61, a), same_screen YES, state 0x2004, keycode 38 (keysym 0x61, a), same_screen YES, Same ctl-a sent, only different is modifier. I bet if you make RU keyboard as #1 and US as #2 Ctl-A will work in RU mode and will not in US mode.
I tried two keyboard orders. 1. US kbd - first RU kbd - second US Ctl-A:state 0x4, keycode 38 (keysym 0x61, a), same_screen YES, RU Ctl-A:state 0x2004, keycode 38 (keysym 0x61, a), same_screen YES, Ctl-A works in US mode only. Here it does not send cyrillic Ctl-A in RU mode. 2. RU kbd -first US kbd- second US Ctl-A:state 0x2004, keycode 38 (keysym 0x61, a), same_screen YES, RU Ctl-A:state 0x4, keycode 38 (keysym 0x6c1, Cyrillic_a), same_screen YES, Ctl-A works in US mode only. Here it does send cyrillic Ctl-A in RU mode. Very strange same keycode witch work in (2) does not work in (1). state 0x2004, keycode 38 (keysym 0x61, a), same_screen YES,
Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc. They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/) for security updates only. If this is a security issue, please reassign to the 'Fedora Legacy' product in bugzilla. Please note that Legacy security update support for these products will stop on December 31st, 2006. If this is not a security issue, please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. If you are currently still running Red Hat Linux 7.3 or 9, please note that Fedora Legacy security update support for these products will stop on December 31st, 2006. You are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a security issue, please change the product as necessary. We thank you for your help, and apologize again that we haven't handled these issues to this point.
Same problem exist in Fedora Core 3, and probably in Fedora Core 5
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp