The fact so far
According to “mod_fcgi is NOT a replacement for mod_fastcgi” and “Issues with mod_fcgid and multi-threaded FastCGI application”, mod_fcgid, is not designed to expect FastCGI servers to be able to handle multiple requests at once, i.e. not designed to expect FastCGI servers to be multi‑threaded.
The former says:
They both support the published "FastCGI" protocol, but how they control their FastCGI servers differs considerably. mod_fcgid quickly eliminates FastCGI servers and starts new ones.
The latter says:
it seems mod_fcgid isn't aware of the fact that my server is multi-threaded and is able to handle more than one request.
That's just two quotes among others, there are some elsewhere.
The consecutive issue
Threading is not only about saving CPU and memory avoiding the overhead of creating a new process (creating a thread is known to be lighter than creating a process), and that could be mitigated by hardware or OS performance; this is also a logical matter, which is less easy to mitigate: threads belongs to a same process, that's not only performance, but also logic, ex. process cannot share what threads could share, as process runs in isolation (modulo IPC, but that's not the same).
At least for this logical reason, the question of multi‑threaded FastCGI server may be raised. A FastCGI server, may hold a context (which may be big and costly to share between processes) which is global to all request handlers when it is designed as a multi‑threaded server. Forking a new process for each concurrent request does not allow to ensure a common context any‑more.
The question
Are the two above quotations still true (one is dated 2011, the other 2010)? I searched the web on the topic, but could not find anything relevant. If it's still true, then, will it always be true or is there an expected plan for mod_fcgid, to be aware of multi‑threaded FastCGI servers and accept these may be designed to handle multiple concurrent requests?