Sounds reasonable to me

Uhh, what. Wayland negotiates protocol versions, the compositor not supporting newer versions should not be an issue.

In fact, the clients using qtwayland were not affected, only the wayland compositor written by qtwayland had a serious bug
At present, nixpkgs probably don`t have any compositor using qtwayland，But the official example of qtwayland can reproduce this bug

I can reproduce this issue in NixOS and openSUSE, but Arch Linux works fine. I found it`s this patch fixed it.

Update: Arch Linux seems to have introduced this patch to fix a bug in Telegram Desktop :

The incompatibility of wl_shm versions makes Telegram Desktop fail to open Mini Apps.

This feels very wrong. I'm willing to merge this because I don't really see major risks, but I would like to also understand how this is causing an issue, because it absolutely should not be.

In fact, the clients using qtwayland were not affected, only the wayland compositor written by qtwayland had a serious bug
At present, nixpkgs probably don`t have any compositor using qtwayland，But the official example of qtwayland can reproduce this bug

But isn't the example a client?

OK so I think the issue here actually is: if the compositor is built with the vendored 1.22 header, and the client is built with 1.23, the client attempts to speak a new version of the protocol to the server, and then dies because the server doesn't understand it.

But isn't the example a client?

The QtWayland module consists of two parts:

Wayland platform plugin:
    Enables Qt applications to be run as Wayland clients.

QtWaylandCompositor API:
    Enables the creation of Wayland compositors using Qt and QtQuick.

qtwayland's example is a wayland compositor using QtWaylandCompositor API.
Similar to wlroots, it support drm/wayland/x11 backends, you can run it as a client, just like you can run sway under sway，the former is drm backend, while the latter is wayland backend

For clients side, all GUI clients can reproduce this bug, even if it's a qt/qml client, it seems that the qtwayland's platform plugin does not use the vendored protocol

looks like https://bugreports.qt.io/browse/QTBUG-126379

It looks like the following upstream issue:
The problem is QtWaylandCompositor uses wayland-scanner with the public-code option. This causes wl_interface definitions to be exported. libwayland also exports a set of protocol definitions of the core protocol.
In this case qtwaylandcompositor has wl_shm_interface corresponding to version 1, libwayland has wl_shm_interface corresponding to version 2. The dynamic linker resolves the symbol to the one from qtwaylandcompositor. Now wl_display_init_shm will call wl_global_create with version 2. This fails because the version is higher than the interface version. In effect no wl_shm global will be present.
This is something most clients cannot cope with.

OK, this makes more sense now.

There seems to be a better solution to the problem:

https://codereview.qt-project.org/c/qt/qtwayland/+/598596

client: Run waylandscanner with private-code

This is the recommended mode, and failing to use private-code
makes libraries expose generated symbols like wl_shm_interface,
which may conflict with symbols from libwayland leading to
unexpected behavior or aborts.

Yes, this was always the intended long term solution.