I've tried this on a couple of occasions but was disappointed to see that it didn't work. I understand that the semantics need some defining, but from the user's perspective there's only one behavior that makes sense: run the next-match based on the node that was matched (which may not be the current node if inside xsl:for-each). Call it the "currently matched node" if necessary. I don't believe it would make sense to say "next-match" on any other node (such as the current node), because there would no longer be a comparison by which another match could be said to be "next"; my point here is that there's no ambiguity problem.

It can be useful for "fanning out" the matched node, where the first match does the fanning and the next match does the processing, all in the same mode. That it's a next match (in the same mode) rather than using a new mode is important because the first-matching template rule could be associated with more than one mode (to support multiple fanning scenarios, for example). Also, you may want to pass a different parameter for each <xsl:for-each> iteration.

My contention is that xsl:next-match (and xsl:apply-imports) should not be defined in terms of the current node but rather the currently matched node, thereby removing the restriction; and that <xsl:for-each> shouldn't nullify the current template rule.

Evan