XSLT 2.0 How to do counters and variables across various loops and structure

So, I know you can't access variables outside scope, that they're immutable, that XSLT is functional not imperative, etc...

But I need a general purpose approach to something that would be trivial with global mutable variables (that sounds evil just saying it :). Here's an example...

<xsl:template match="t1">
  <xsl:if test="someLogic">
    <!-- I know, can't do this but just to explain... -->
    <xsl:variable name="varName">numberOrText, maybe even some arithmetic like $varName+1</xsl:variable>
  </xsl:if>
</xsl:template>

<xsl:template match="t2">
  <xsl:value-of select="$varName"/>
</xsl:template>

And the challenge is there could be any number of templates like t1 and t2 at any time during processing and templates that both modify and use the variable.

Maybe part of the problem is that the values depends on the order of processing, but that's deliberate--that's what is required.

One possibility I thought of was to pass the values everywhere as parameters. But the problem is that one leaf template might need to change it, and then processing goes back up... it loses that change. Unless there is some way for a template to return parameters and then I could pass those returned parameters on? Thinking of a general purpose pure functional programming language, it seems like that's how one might do this--calling recursively, but using the return values for further calls so one can "carry forward" the values.

I have seen this done using extensions--calling out to Java methods or something like that and then you can have global mutable values, but... I'd really rather not "cheat" like that.

An开发者_StackOverflowy pointers, ideas, etc., welcome.

I think the answer was included in my question and other comments. Here's quoting some of it:

"some way for a template to return parameters and then I could pass those returned parameters on? Thinking of a general purpose pure functional programming language, it seems like that's how one might do this--calling recursively, but using the return values for further calls so one can "carry forward" the values."

From user357812: "I think that maybe this can be done with a most fine-grained tree traversal pattern and tunnel param. Only with input and output it's posible to say exactly how."