If QThread::wait is called after the run() implementation has returned, but before the thread's entry point function (i.e QThreadPrivate::start) has returned, then QThread::wait will not wait at all if the QThreadPrivate::finish function has already set the "running" and "finished" flags.
As the finish function also closes and resets the handle, QThread::wait will not be able to wait for anything anymore. This causes problems (crash) if QThread::wait returning indicates that i.e a DLL in which the thread runs can be unloaded, which might also unload Qt. In this case, the code of the thread function that is still running will be removed from memory (not unlikely if the thread runs on low priority).
This task has been rescheduled to 4.5 due to the destabilization risk associated with it. Initial attempts at fixing the problem have shown that much of QThread will need to be rewritten.
Even after stopping the thread, Qt code may still be executing when the library is unloaded. Fixing this is going to require much more work than originally thought.