Race conditions/improper texture handling in multi-screen wayland compositor

If I start the multi-screen example compositor on a system with two or more displays connected with QT_QPA_PLATFORM=eglfs and then start one or more applications (examples/opengl/hellogles3 or examples/qt3d/planets-qml seem to be good choices), I will (on a current Ubuntu with an AMD GPU) after a while start to see messages like the following, especially if I move the mouse cursor over a window:

QOpenGLTexturePrivate::destroy() called but texture context 0x55e895f6c280 is not shared with current context 0x55e895edc1b0.
Texture has not been destroyed

This  happens with the distribution packages (version 5.14.2) as well as for Qt built from source with "-opengl es2" for 5.12.8, 5.12.9, 5.14.2, and 5.15.1. (And if I add the currentContext checks from QOpenGLTexture::destroy() to QOpenGLTexture::bind(), too, it will print those log messages as fast as the terminal will scroll.) None of these messages are displayed if I use the compositor from examples/wayland/qwindow-compositor, which uses only the first screen.

I haven't yet seen the log messages on a yocto build with Qt 5.12.8 for an i.MX8 (which is the platform I actually care about) with the Vivante graphics driver, there I see segfaults when a texture is used that has just been destroyed in another thread. Again, those segfaults appear faster if there are more windows open or if I move the mouse.

#0 0x0000ffffb40b6934 in gcsSURF_NODE_GetHardwareAddress () from /usr/lib/libGAL.so
#1 0x0000ffffb41458f8 in ?? () from /usr/lib/libGAL.so
#2 0x0000ffffb40dae74 in gcoTEXTURE_BindTextureDesc () from /usr/lib/libGAL.so
#3 0x0000ffffb4619f8c in ?? () from /usr/lib/libGLESv2.so.2
#4 0x0000ffffb45f3ff4 in ?? () from /usr/lib/libGLESv2.so.2
#5 0x0000ffffb461b124 in ?? () from /usr/lib/libGLESv2.so.2
#6 0x0000ffffb461efb0 in ?? () from /usr/lib/libGLESv2.so.2
#7 0x0000ffffb45f4a0c in ?? () from /usr/lib/libGLESv2.so.2
#8 0x0000ffffb45ab648 in ?? () from /usr/lib/libGLESv2.so.2
#9 0x0000ffffb457ef90 in glDrawElements () from /usr/lib/libGLESv2.so.2
#10 0x0000ffff8a75e698 in QSGBatchRenderer::Renderer::renderMergedBatch(QSGBatchRenderer::Batch const*) () from /usr/lib/libQt5Quick.so.5
#11 0x0000ffff8a75f5c8 in QSGBatchRenderer::Renderer::renderBatches() () from /usr/lib/libQt5Quick.so.5
#12 0x0000ffff8a76450c in QSGBatchRenderer::Renderer::render() () from /usr/lib/libQt5Quick.so.5
#13 0x0000ffff8a75687c in QSGRenderer::renderScene(QSGBindable const&) () from /usr/lib/libQt5Quick.so.5
#14 0x0000ffff8a756cd8 in QSGRenderer::renderScene(unsigned int) () from /usr/lib/libQt5Quick.so.5
#15 0x0000ffff8a78ee8c in QSGDefaultRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () from /usr/lib/libQt5Quick.so.5
#16 0x0000ffff8a7ef810 in QQuickWindowPrivate::renderSceneGraph(QSize const&) () from /usr/lib/libQt5Quick.so.5
#17 0x0000ffff8a79a950 in ?? () from /usr/lib/libQt5Quick.so.5
#18 0x0000ffff8a79e358 in ?? () from /usr/lib/libQt5Quick.so.5
#19 0x0000ffffb4af3e30 in ?? () from /usr/lib/libQt5Core.so.5
#20 0x0000ffffb46f5774 in ?? () from /lib/libpthread.so.0
#21 0x0000ffffb47e9bfc in ?? () from /lib/libc.so.6

According to the board manufacturer support, a similar thing seems to happen on Intel Apollo Lake SoCs.