I would separate the objects into two types. One type that is the "master" object and other objects which interact with it.
That's the correct thinking, I consider this whole question to be a design issue. The problem I see is that a dependency is introduced between two QObjects that are in different threads, that is very unnatural to begin with - the two objects shouldn't depend on one another implicitly; it's no mistake that a QObject instance can't have a parent that's living in another thread. In my mind either the dependency should be declared explicitly (e.g. manually synchronizing the objects across the threads in some fashion) or it shouldn't exist at all.
I have some experience in software development (about 30+ years or so), and never ever was your question leading...
First choose what devices your app should be running on
Then decide if your app has enough "reusable" things to even start thinking about models
If not, don't use any model at all! It will only cost you more time. Don't let the "hype" trick you!
However, if ur app is supposed to work on several different devices, and the output of your app may be in different kinds of forms, THEN, and only THEN, start thinking about how to generalize the view of ur app to the different kinds of users...
And also ofcourse, If you plan to make many apps, some parts may be common. And Yes, in that case you start worying about reusability.
Worry about UI, before u have thought about ur app first:
What it should do
How it should do it
What UI should be the LAST of ur problems...
Now, having sayd that, there is always "Prototyping" to engage the end users in the look and feel of the app in as early a stage as possible of course, but it NEVER should be leading to a change of architecture.
However in my experiece, MVC cannot be implemented as cleanly as in a web application for a desktop application. Main reasone is that all UI widgets have some sort of controller embedded in already.
For that reason Qt has something called Model-View architecture which is not the MVC pattern but something similar to de-couple your data from the view.
Qt only applies the view as controller, but doesn't actually "require" the user programmer to follow. The same effect as and I'd say better could be obtained by separating the logic. One thing that springs to mind: no need to derive a whole class only to have a form initialized in the constructor.
The only problem with MVC is that it's used with and without reason (as all "architectural" and "design" patterns are), because people are mislead to believe them as one size fits all solution.
Middleware - a mechanism to extend the functionality of dispatcher allowing for advanced asynchronous workflow and integration with visual component like FileDialog.
Store - A replacement of AppListener that could listen from non-singleton dispatcher, and re-dispatch the action message to another Store components sequentially. It could avoid the over-complicated waitFor mechanism.
Hydration - Serialize and deserialize a store to/from a QVariantMap object.