Citando a documentação em:
o comportamento é:
If the WSGIDaemonProcess directive is specified outside of all virtual host containers, any WSGI application can be delegated to be run within that daemon process group. If the WSGIDaemonProcess directive is specified within a virtual host container, only WSGI applications associated with virtual hosts with the same server name as that virtual host can be delegated to that set of daemon processes.
Assim, você pode alcançar a definição do processo do daemon no host virtual anterior, desde que tenha o mesmo nome de servidor.
Você também precisa estar ciente do que é dito em:
pelo qual, por padrão, para WSGIApplicationGroup (ou seja, se não especificado) é:
%{RESOURCE}
The application group name will be set to the server hostname and port as for the %{SERVER} variable, to which the value of WSGI environment variable SCRIPT_NAME is appended separated by the file separator character.
For example, if the virtual host www.example.com was handling requests on port 8080 and the URL-path which mapped to the WSGI application was http://www.example.com/wsgi-scripts/foo, then the application group name would be set to www.example.com:8080|/wsgi-scripts/foo.
The effect of using the %{RESOURCE} variable expansion is for each application on any server to be isolated from all others by being mapped to its own Python sub interpreter.
Portanto, normalmente, se você tivesse WSGIScriptAlias separado para o mesmo ponto de montagem nos dois hosts virtuais para portas diferentes, as duas instâncias do aplicativo ainda seriam separadas, executando-se em diferentes sub-intérpretes.
Existe uma exceção a essa regra no caso da porta 80/443, na qual a porta não está realmente incluída no nome do grupo de aplicativos. Assim, nesse caso, os aplicativos montados no mesmo ponto de montagem seriam executados no mesmo subinterpretador.
Essa exceção provavelmente não é explicada da forma mais clara possível, mas é coberta pela definição:
%{SERVER}
The application group name will be set to the server hostname. If the request arrived over a non standard HTTP/HTTPS port, the port number will be added as a suffix to the group name separated by a colon.
For example, if the virtual host www.example.com is handling requests on the standard HTTP port (80) and HTTPS port (443), a request arriving on either port would see the application group name being set to www.example.com. If instead the virtual host was handling requests on port 8080, then the application group name would be set to www.example.com:8080.
essa expansão do que está sendo usado como parte da expansão padrão acima.