Third-level keyboard shortcuts are ignored (QXcb)

There is a bug with shortcuts in the Neo 2 layout, and in custom layouts that use third-level for special keys: https://bugs.kde.org/show_bug.cgi?id=343629.
The bug manifests itself in Kate and in other KTextEditor-based applications because KTextEditor handles Left, Right, BackSpace, etc. keys as shortcuts.

For example, when the conventional arrow key is pressed, it is recognized as the Left shortcut key. However when the user tries to press the combination AltGr+S, which also means "Left" in the Neo layout, QXcbKeyboard::possibleKeys returns (73), which causes Possible shortcut key sequences: QVector(QKeySequence("I")) in QShortcutMap::find, and then causes QShortcutMap::nextState(QKeyEvent(ShortcutOverride, Key_I, text="i")) = 0 in QShortcutMap::nextState. This results in the alternative "Left" key being ignored. The same about other special 2-key combinations.

I tracked the issue to the following lines in QXcbKeyboard::possibleKeys:

xkb_keysym_t sym = xkb_state_key_get_one_sym(kb_state, keycode);
...
int baseQtKey = keysymToQtKey(sym, modifiers, lookupString(kb_state, keycode));
if (baseQtKey)
    result += (baseQtKey + modifiers);

I believe that we shouldn't retrieve just one key symbol in this case, because it returns a single letter key ("I").

Currently there is a simple workaround for this issue: insert the line nativeScanCode = 0; before

QKeyEvent keyEvent(QEvent::ShortcutOverride, keyCode, modifiers, nativeScanCode,
        nativeVirtualKey, nativeModifiers, text, autorepeat, count);

in QWindowSystemInterface::handleShortcutEvent.
Passing 0 as nativeScanCode eventually results in the

if (!e->nativeScanCode()) {
    if (e->key() && (e->key() != Qt::Key_unknown))
        result << int(e->key() + e->modifiers());

code from QKeyMapper::possibleKeys to be executed instead of QXcbKeyboard::possibleKeys. And with this code special shortcuts work fine. Of course, this workaround would probably cause other shortcuts to work incorrectly, so I think that QXcbKeyboard::possibleKeys should be fixed somehow.

This bug may be related to QTBUG-53006.