capslock(ctrl_modifier) generates invalid modifier map

This bug applies to Ubuntu 14.04 (Trusty Tahr)

I configured my (GNOME) desktop to make Caps_Lock an additional Control key.

This results in a perfectly reasonable xkb keymap:

xkb_keymap {
 xkb_keycodes { include "evdev+aliases(qwerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+us+inet(evdev)+capslock(ctrl_modifier)+compose(ralt)" };
 xkb_geometry { include "pc(pc105)" };
};

But "xkbcomp" turns this into a slightly broken modifier map:

shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Caps_Lock (0x42), Control_R (0x69)
mod1 Alt_L (0x40), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)

As you can see, Caps_Lock is now assigned to both "lock" and "control". That's technically not valid, even if it happens to (almost) work with many X applications.

Unfortunately for me, VMware Workstation is one of the applications that cannot handle this situation. In fact, when it encounters this type of modifier map, it proceeds to completely clear the entire map, which is quite catastrophic:

xmodmap: up to 0 keys per modifier, (keycodes in parentheses):

shift
lock
control
mod1
mod2
mod3
mod4
mod5

That's of course a bug in VMWare -- and I already reported it. But the root cause of the bug looks as if it is faulty information in the xkeyboard configuration files.

For the time being, I can work around the problem by issuing "xmodmap -e 'clear lock'" prior to starting VMWare Workstation.