In the era of parallel processing it's so natural to inscribe your favorite programming language in the league of "Multithreading supporter". I've seen such appeals before "Wide Finder in XSLT --> deriving new requirements for efficiency in XSLT processors."
... I am not aware of any XSLT implementation that provides explicit or implicit support for parallel processing (with the obvious goal to take advantage of the multi-core processors that have almost reached a "prevalent" status today) ...
I think both xslt and xquery are well fitted for parrallel processing in terms of type system. This is because of "immutable" nature (until recent additions) of the execution state, which prevents many race conditions. The only missing ingredients are indirect function call, and a couple of core functions to queue parallel tasks.
Suppose there is a type to encapsulate a function call (say function-id), and a function accepting a sequence and a function-id. This function calls function-id for each element of the sequence in a parallel way, and then combines a final result, as if it were implemented serially.
Pretty simple, isn't it?
This function runs $id function for each item in a sequence.
$items - items to process.
$id - function id.
Returns a sequece of results of calls to $id function.
<xsl:function name="x:queue-tasks" as="items()*">
<xsl:param name="items" as="item()*"/>
<xsl:param name="id" as="x:function-id"/>
<!-- The pseudo code. -->
<xsl:sequence select="$items/call $id (.)"/>
a@href@title, b, blockquote@cite, em, i, strike, strong, sub, super, u