The same will happen if only the main thread can display.  If a
    non-main thread wants to prompt the user, it will have to wait until
    the main thread becomes available, prompts the user, and returns the
    response.

    Someone always has to wait when threads need to synchronize.  There's
    no way around that.  Doing this in the thread that needs to
    display/prompt is easier because the context and relevant variables
    don't need to be communicated to another thread.

Sorry for my poor English.

Message queue is a good solution for parallel and concurrence.

I think it is not a good idea to let all threads to do display things directly.
It will be better to let non-main threads to do display things via message queue,
like many GUI toolkit does. It is also like the message loop in Emacs.
This will make many things easier.

For GUI toolkit on windows, there are two basic API: Sendmessage and PostMessage.
Non-gui thread can use theme to do display and UI related things.

For example in Emacs, when a non-main thread calls `message', a small display task is built
and put into the message queue of the main thread, like `PostMessage` does.
If it calls `read-file-name`, an UI task is built and put into the message queue of
the main thread like `SendMessage` does, while the caller thread will be blocked until result comes.

When all display jobs are all in one thread (decoupled with other threads), display jobs may be scheduled
more efficiently and may be concurrent internally.