OK, fair point. (Although, if I'm reading the bug reports correctly, the issue there looks more like GTK3 "not interfering enough" with KDE, that is, not reading dpi configuration from the same place as KDE, and requiring to edit a different file instead.)

In other words: lack of integration, as already pointed out - which is quite the opposite to mrmazda's argument that Qt and GTK "interfere" with each other...

Which environment or component should do this "integration"? X? Wayland? Every window manager? Every DM? Every DE? When and where need it be set? GTK usurped a long existing xrdb option, to use as its personal scaling knob, without which set to something other than 96, GTK apps, via GTK library, glue it to 96 DPI instead of leaving it null, unless OS is (SLE? or) openSUSE.

Your the one telling the story. So what's the answer then?

So this is what your beef really is about? If I'm correct in my understanding of what your really talking about; the issue is with the xsettings plugin in the GNOME Settings Daemon ignoring X settings as described here. This also seems to be related to HiDPI displays, and not all displays. There also seems to be workarounds for this problem, like this thread among many others.

In KDE there's also System settings > Fonts > Force Fonts DPI - which I've had to do even just running Qt apps because I disabled using the DPI reported by NVIDIA's closed-source driver. Forcing the DPI in KDE System Settings DOES work for Qt apps. There's also Xft.dpi: 96 in /etc/X11/Xresources which should also work for Qt apps (not sure which config file KDE System Settings uses for the Force Fonts DPI setting in that).

The point remains that if GTK and Qt/KDE aren't getting their settings from the same place, then how does Qt "interfere" with GTK or vica versa ? So that once again proves the opposite to what you're saying about GTK and Qt "interfering" with each other, if anything. In other words: the issue you seem to be talking about isn't Qt related, and it's related to GTK.