Given that, I don't even know what a "thread-safe qapplication factory" is supposed to mean.
Agreed. I read the original post, thought about it a lot, and couldn't come up with any reply because the entire premise doesn't make sense. The Qt framework is based upon there being a single Qt application object instance per running instance of an executable, and trying to create more than one, even if it succeeded, would probably break the application.

assert(app!=nullptr);// its not nullptr, so it has been created.
As soon as a QCoreApplication instance is created, app is non-null.

if exec has been called
-Your application- calls exec(). It isn't mysteriously called from somewhere within Qt, so there is no need to check on it. Nothing really happens in a Qt program until QCoreApplication::exec() is called and the main event loop starts running. Your MainWindow hierarchy might get created (through calls to setupUi(), but nothing actually happens until the call to exec(). You aren't going to receive any signals, no UI or timer events will be issued, no QThread signals will be processed in the main thread even if the threads themselves are started. I am not even sure it is possible to start a QThread running until the main event loop has been started through exec().

Dynamically loaded libraries (DLLs in the Windows world) do not have a QCoreApplication instance; they use the one created by the main executable that loads them. So do QThread instances created by an application.

So it seems like your whole line of questions is based on a misunderstanding of the Qt application architecture. Maybe you are confusing QThread and QProcess? Or confused about QEventLoop, of which there can be multiple instances in an application?