Divergence in "behaviours" and "generally agreed-upon layouts" is possible even with native toolkits, so I fail to see how Qt or Tk are a relevant factor here (both of them give the programmer the necessary tools to match the native behavioral and layout conventions, just like the native toolkits do).

Tk definitely has a disadvantage in the "accessibility" category, but Qt literally uses and abstracts the native accessibility interfaces¹, so in Qt's case this should be a non-issue (beyond the typical considerations for software accessibility that apply even for native toolkits, like, you know, actually leveraging and testing those features).

> I have not seen a Qt app on macOS that did not stand out like a sore thumb on the very first glance.

Okay, but by virtue of knowing what Qt even is, I'd wager that you ain't an ordinary user. The vast majority of end users will neither notice nor care (especially given that there's an abundance of commonly-used software that deviates from the typical macOS UX even without Qt, e.g. Office and Chrome, or pretty much every single app using Electron or CEF or some other browser-as-UI approach). The only thing that truly matters is whether or not the software works and is usable, and Qt doesn't really pose any obstacle there (and Tk only does if accessibility is a concern - which I'd argue it should be, but it's at least no worse than the status quo).

----

¹: https://doc.qt.io/qt-5/accessible.html