ABI mismatch between KDE Platform and PySide6 Base App (undefined symbol ... version Qt_6_PRIVATE_API)

*TLDR: What is the current status regarding the KDE Platform and PySide6 ABI mismatch caused by Qt patch updates and how to handle it correctly as an application maintainer?*

In the past, there has been an issue with an ABI mismatch between `org.kde.Platform` and `io.qt.PySide.BaseApp` when the PySide base app is updated with a delay after the KDE Platform.
For example, when `io.qt.PySide.BaseApp` was still at `6.10.2` while `org.kde.Platform` was already at `6.10.3`, the app relying on PySide6 crashed with the error `QtCore.abi3.so: undefined symbol: _ZN14QObjectPrivateC2E16QtPrivate_6_10_2, version Qt_6_PRIVATE_API`.
The issue was fixed by bumping the Qt version of the PySide6 base app to the Qt version of the KDE Platform, see https://github.com/flathub/io.qt.PySide.BaseApp/pull/37.

In #37, there was also a discussion about how it could be solved in the future. It was suggested to include PySide6 in the KDE Platform instead of shipping a separate base app. The same is true for `io.qt.qtwebengine.BaseApp`. The main disadvantage of this is the size increase of the KDE Platform when including both PySide6 and Qt WebEngine. I assumed that many apps are relying on them, but according to the Flathub statistics, there are way fewer downloads for PySide6 than for KDE Platform.
An alternative would be to only update KDE Platform once the updates for the PySide6 and Qt WebEngine base apps are finished so that they are merged within a few minutes/hours. It seems like there are separate maintainers for each.

Since there is currently a discussion about updating the KDE Platform for ProtonUp-Qt from the end-of-life 6.9 to 6.11 (https://github.com/flathub/net.davidotek.pupgui2/issues/51), I was wondering what the current status of this is and what's the best thing I should do. Is it planned to do something about this issue or has there already been something improved since then? I do not want ProtonUp-Qt to break regularly because of this (I already had to downgrade the KDE Platform version twice this year). I'm considering including a copy of Qt+PySide6 inside the ProtonUp-Qt Flatpak instead of relying on the KDE Platform and the PySide6 base app, but I don't think this is an elegant solution.

@Erick555 @Justinzobel @hfiguiere @bbhtt (sorry for tagging everyone, but a sometimes-broken base app seems like a relevant issue to me)

## References

- https://github.com/flathub/net.davidotek.pupgui2/pull/43 (ProtonUp-Qt, ABI mismatch 6.10.0 vs. 6.10.2)
- https://github.com/flathub/net.davidotek.pupgui2/pull/48 (ProtonUp-Qt, ABI mismatch 6.10.2 vs. 6.10.3)
- https://github.com/flathub/org.torproject.torbrowser-launcher/issues/180 (TOR Browser, ABI mismatch 6.10.0 vs. 6.10.2)
- https://github.com/flathub/io.github.qcanvas.QCanvasApp/pull/23 (QCanvas, ABI mismatch 6.10.0 vs. 6.10.2)
- https://forums.linuxmint.com/viewtopic.php?t=469388
- https://discuss.kde.org/t/pyside6-broken-after-qt-upgrade-to-6-10/42266
- https://github.com/flathub/org.torproject.torbrowser-launcher/issues/234
- https://invent.kde.org/packaging/flatpak-kde-runtime/-/work_items/79

No source file or test is named. Start by reading the discussion in issue #37 and the referenced KDE packaging work item 79, then compare the documented PySide6 and KDE Platform update paths. Done would require an agreed, maintainable way to prevent or handle the ABI mismatch for application maintainers.

Written by the indexing model from the issue text.