Parallel execution of multiple queries is just one use case in a family of many others, and I agree with Lance's post in the list that it would be better to make an extensible component.
Other similar use cases often requested: multi source federation, factor in ad service, select sources based on query analysis, select sources based on results, non-solr sources, result modification based on content in result, query abstraction layer/templating
The common goal is to make an abstraction layer on top of search sources which can handle search-close functionality and thus not need implement this in all the front-ends. Other products which try to fill this role are: FAST Unity, Comperio Front, Sesat (sesat.no)
Perhaps the /multi req.handler could be the start of such a framework, where the first plugin to implement is the parallel queries use-case.
To be able to handle a high count for "n" without hitting HTTP GET limitaions, and get a cleaner syntax for complex cases, the handler could accept the request as a POST. Pseudo post content, could be JSON or custom:
<src name="yp">q=category:$q^10 OR company:$q&rows=3</src>
The result list would then consist of five entries named web, yp, google, wp and ads.
Each "branch" and "src" would be pre-defined in config, specifying the implementing class and any defaults. indeed, the whole POST could be pre-configured, only needing to supply a &steps= param to identify which "template" to choose, using $variables for q etc.
The class implmenting "steps" simply calls each sub step in sequence, passing the request and response objects. This provides a simple framework for future extensions, pre- or post-processing.
The class implementing "branch" of type "list" would spawn all sub queries as threads and include each source result in a list.
Another implementation type of "branch" could merge (federate) results instead of stacking them.
The class implementing a "src" would be a thin wrapper which simply dispatches the query to the Search RequestHandler. Other implementations of "src" could be wrappers for external engines like Google or ad servers.
My intention is not to suggest a huge component, but consider if a smart interface design could enable very powerful extension possibility which will be useful in almost all portal type applications.