I don't have a reply button anymore to sho_hn's comment. Take this as a reply to the adjacent comment :)
What I am saying is: if you have a new _native_ widget in a new OS release (layout spacing, new views, new controls, new features - there are so many), it won't be implemented in the Widget code base. The Qt project will tell you to use QML. How are you going to make your C++ Widget based app look modern now when all your code is QML based?
Answer: there is no answer. The Qt project has made it extremely difficult to decide for their existing users. For new users, it's a trivial task to choose QML but how many new desktop apps are being developed from scratch these days.
Several of the things you list are the duty of the platform plugin and the style engine plugin and don't actually require any changes to the core widgets. Yay layering.
Personally I think entirely new widget classes should be accepted into the QWidgets module, but you may be right that there's some resistance to that - but the bar for new widgets has always been fairly high actually, it was a rare occurence even before QML (neither Qt 3 or Qt 4 saw much in the way of new widgets during their respective lifetime). I think the case that a lot of the "new UI challenges" are better met by QML is also somewhat legitimate, in which case there's an incentive for porting to it.
What I am saying is: if you have a new _native_ widget in a new OS release (layout spacing, new views, new controls, new features - there are so many), it won't be implemented in the Widget code base. The Qt project will tell you to use QML. How are you going to make your C++ Widget based app look modern now when all your code is QML based?
Answer: there is no answer. The Qt project has made it extremely difficult to decide for their existing users. For new users, it's a trivial task to choose QML but how many new desktop apps are being developed from scratch these days.