Probably require fix for 8 and 7 too.

Okay so I did a little more digging and mutter is doing extra work it doesn't need to that's leading to the failure. This (look for the removed lines below) side-steps the bug:

 static gboolean
 meta_keymap_x11_replace_keycode (MetaKeymapX11 *keymap_x11,
                                  KeyCode        keycode,
                                  KeySym         keysym)
 {
...
           int types[XkbNumKbdGroups] = { XkbOneLevelIndex };
           XkbChangeTypesOfKey (xkb, keycode, 1, XkbGroup1Mask, types, &changes);
           XkbKeySymEntry (xkb, keycode, 0, 0) = keysym;
...

-      changes.changed = XkbKeySymsMask | XkbKeyTypesMask;
-      changes.first_key_sym = keycode;
-      changes.num_key_syms = 1;
-      changes.first_type = 0;
-      changes.num_types = xkb->map->num_types;
       XkbChangeMap (xdisplay, xkb, &changes);
...
}

You see, mutter is telling the X server that it updated the key types data by putting XkbKeyTypesMask in the changed field.  But it didn't update the key types data.
All it does above is assign the "ONE_LEVEL" key type to the passed in key. "ONE_LEVEL" is a builtin key type that means the key shouldn't change its output when the shift key is held down.

From what I gather, XkbKeyTypesMask is for changing e.g. the number of shift levels a given key type has (e.g. you could copy ONE_LEVEL to a new key type MY_LEVELS and then give it 2 shift levels). 

So, anyway, mutter shouldn't be setting the mask saying the key type data changed and the key type data isn't getting touched.
This is extra clear, because it's passing for the "changed" types, 0 through map->num_types (all of them!). In other words, mutter is passing all the types unmodified to the X server for no particularly
good reason. 

Furthermore, XkbChangeTypesOfKey already preps the changed structure with the right data, because it's changing the key itself, so mutter doesn't actually need to mess around with the changed mask again itself at all.

Of course there's still an X server bug here. The X server only allows type data be sent in the request if the client says the number of types changed. That's wrong, which means 3 from comment 0 is the right fix. So I think we should fix the X server downstream, and simplify mutter upstream.

https://gitlab.com/redhat/centos-stream/rpms/xorg-x11-server/-/merge_requests/3

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: xorg-x11-server), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2414