My application has a setting where you can choose whatever arbitrary scale you want, smaller or larger than default.

Qt 5 defaults to "DPI scaling off", where text is enlarged but 1px is always 1px regardless of the current scale (so UI elements sized in px can end up too small on HiDPI displays). It has a mode with DPI scaling on, where 1px could be a fractional or integer number of on-screen pixels. Qt 6 only supports this latter mode.

Qt 5 defaults to rounding the magnification factor (output physical pixels / input program-facing virtual pixels) to an integer (except on KDE where it's passed through), while Qt 6 defaults to passing it through as a real number. (Qt 5.14+ and Qt 6 allow apps to customize what rounding method is used, except on KDE where it's passed through no matter what your app requests.) Passing through non-integer scale factors causes Qt's Windows-style theme (and some apps as well) to break spectacularly with rounding errors left and right, shifting as you move your mouse and focus between widgets. Breeze and Fusion handle this better (in my opinion using hacks rather than logical principled fixes), but I still prefer integer scale factors where I'm guaranteed that each x-by-y rectangle is the same integer number of on-screen pixels (which is useful for creating correctly sized off-screen buffers and blitting regions between graphical buffers).

All in all, if you drag a window between screens, Qt apps should handle it mostly fine. However, Qt doesn't properly respond when a display changes scale factor (like switching from laptop-only to external-only, or changing the scale factor of a monitor for testing), because Qt only checks for scale factor changes when the screen ID changes.

Unfortunately Qt makes it hard for apps to properly handle changing scale factors. If you cache the size of text in pixels, or "64 px * current scale factor", then the app changes scale factors, the app will resize, but your cached sizes won't change. I think property binding is a good solution to this (easier to use than Qt's private events, or handling QScreen-changed or QScreen-property-changed signals), but Qt isn't currently built around property binding. Maybe in a few years, Qt 6 will port the long tail of APIs to QProperty... I can only hope...

(Also Qt Creator's "new file" wizard somehow managed to have broken layout (too-small QLineEdit text fields) even when opening the app on a constant non-changing 125% scale. I suspect it's related to constructing a QFont without passing in a widget for context, causing it to use the global scaling instead of the current window's scaling. Or maybe it's because on Qt 5, Qt defaults to something like unscaled MS Shell Dlg 2 rather than scaled lfMessageFont.)