Compose key no longer works in Qt-based apps

As of roughly a month or two ago, the compose key has not been working for me in Qt-based apps. Affected software: all KDE apps and Telegram (which is Qt-based). GTK-based apps and Electron-based apps are not affected.

What happens is that when I type, for example, "<compose> e =", I get a Euro currency symbol as expected in GTK-based apps and Electron-based apps. In Qt-based apps, I get "e=".

I have my compose key mapped to my laptop's physical caps lock key, using the standard "Position of compose key: Caps Lock" XKB advanced option.

Relatedly, in the console output of Qt-based apps, I see the following errors:

xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:39:34: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:40:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:41:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:42:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:43:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:44:27: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:45:27: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:46:27: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:47:27: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:48:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:49:29: string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:49:29: too many errors
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:49:29: failed to parse file

And here are those mentioned lines from the /usr/share/X11/locale/iso8859-1/Compose file on my system:

<Multi_key> <exclam> <exclam>        : "\241"    exclamdown
<Multi_key> <c> <slash>            : "\242"    cent
<Multi_key> <slash> <c>            : "\242"    cent
<Multi_key> <C> <slash>            : "\242"    cent
<Multi_key> <slash> <C>            : "\242"    cent
<Multi_key> <C> <bar>            : "\242"    cent
<Multi_key> <bar> <C>            : "\242"    cent
<Multi_key> <c> <bar>            : "\242"    cent
<Multi_key> <bar> <c>            : "\242"    cent
<Multi_key> <l> <minus>            : "\243"    sterling
<Multi_key> <minus> <l>            : "\243"    sterling
<Multi_key> <L> <minus>            : "\243"    sterling

It seems to be complaining about lines with a backslash in them.

I believe this may be a Qt regression as my version of libxkbcommon has not changed recently and the file in question is over a year old:

$ ls -larth /usr/share/X11/locale/iso8859-1/Compose
-rw-r--r--. 1 root root 20K Jul 21  2022 /usr/share/X11/locale/iso8859-1/Compose

And this definitely worked from 21 July 2022 until recently!

Thus it seems as if something in Qt has changed to parse this file differently, in a way that interprets the contents of the file as invalid for Qt apps and prevents the compose key from working. Again, compose key functionality works just fine in GTK and Electron apps.

I'm using KDE Plasma, with Qt 5.15.8, plus KDE's backported patches from Qt 6. The issue is reproducible on both X11 and Wayland. It's also reproducible both in Plasma 5.26 and also current git master which will become 5.27 soon.

The timeline of the regression roughly lines up with either the Qt 5.15.8 or 5.15.7 update, but I don't have the ability to easily revert the entire Qt stack to test that theory, unfortunately.