I found out it is more serious than expected.
In the cases where application (OpenOffice.org this time) will grab your input
(like if using popup menus) and stops responding - you no longer can switch to
the text console and free your mouse/keyboard by kill(1)ing of that app.
Mouse still moves on the X screen but the clicks have no longer any effect.
(These cases are not reproducible for me, otherwise they would get bugreported.)

do you have xkeyboard-config installed ?

Created attachment 138667 [details]
rpm --qf "%{name}-%{version}-%{release}.%{arch}\n" -qa|sort|

Yes: xkeyboard-config-0.8-7.fc6.noarch
Full "rpm -qa" attached.

I have got same problem with FC6.

`chvt 1' works as a workaround but usually one cannot enter it with a grabbed
keyboard input.

I appear to have the same problem with FC6. When I hit CTRL-ALT-F(1..6) the
screen goes blank and the system appears to hang as I can neither shut
down with a short power button, nor can I access it remotely. CTRL-ALT-F7
does not bring it back either.

Same prob here with FC6. I have also found problem with keyboard indicator
crashing just after logon
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213163) - could these bugs
be related?

This issue is rather complicated. Now I am on FC6/x86_64. There are situations
where switching works (a bit) and other where it doesn't work.
It works when
  - only one keyboard is defined in both System/Preferences/Keyboard=S/P/K and
System/Administration/Keyboard=S/A/K
  - I have two keyboards in S/P/K (US and Czech) and I switch it in S/A/K
(between US and US international), but only during the session
  - on my notebook S/A/K is US (propagated into xorg.conf) and in S/P/K I have
US international and Czech qwerty

Another issue is what happens when Gnome asks "use X or Gnome settings for
keyboard".

It should be possible to define some patterns from this behaviour, but will
require a lot of time (at least).

*** Bug 212530 has been marked as a duplicate of this bug. ***

However same thing comes with Fedora 7.

Could this be a problem with the czech xkb layouts? Note mostly .cz people are
cced here.

I use FC7 and as I use only MOUSE to switch keyboard layouts I don't have such 
a problem

MP

Workaround from tmraz:
Alt/Win key behavior->Meta is mapped to the Win-keys.
(besides that also using:
Group Shift/Lock behavior->Right Win-key switches group while pressed.
Use keyboard LED to show alternative group->ScrollLock LED shows blahblah.
)
Primary keyboard: U.S. English
Secondary keyboard: Czechia qwerty

Still the switching is possible only by right-ctrl/alt-F1 (not left-ctrl/alt-F1).

In Fedora 8 everything works as expected, no workarounds needed (AFAICT).

With linux-2.6.23.9-67.fc8, I have a same problem.
But with linux-2.6.21-1.3194.fc7, I have not a same problem.
And with linux-2.6.24-0.63.rc3-git6.fc9, a same problem is remained.
My keyboard is japanese 106.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

What's the status of this bug?

upstream Xorg had a number of vt switching and many of them are resolved now in
server 1.5 (F9). Switching between us, de and cz layout works fine here,
including VT switches.

The problems with the czech keyboards are solved since F8, so the japanese
keyboard can be the remaining problem (comment #15), setting NEEDINFO.

Masao, can you switch between console and logged-in Gnome session with upgraded
F9, please?

(In reply to comment #19)
> Masao, can you switch between console and logged-in Gnome session with upgraded
> F9, please?
Yes, I can .

Calling it fixed then.