Quoting the documentation at:
http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
behaviour is:
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.
So, you can reach across to daemon process definition in prior virtual host so long as same server name.
You also need to be aware of what is said in:
http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIApplicationGroup
whereby for default for WSGIApplicationGroup (ie., if not specified) is:
%{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.
So, normally if you had separate WSGIScriptAlias for same mount point in the two virtual hosts for different ports, the two application instances would still be separated by running in different sub interpreters.
There is an exception to this rule though for the port 80/443 case whereby the port isn't actually included in the application group name. Thus in that case, applications mounted at same mount point would run in same sub interpreter.
This exception probably isn't explained as clearly as it could, but is covered by the definition:
%{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.
that expansion of that being used as part of the default expansion above.