Evaluating replace on string-replace

Consider this pipeline fragment:

<p:for-each>
  <p:variable name="opos" select="p:iteration-position()"/>
  <p:for-each>
    <p:iteration-source select="//div"/>
    <p:string-replace match="/div/@a" replace="3+4"/>
  </p:for-each>
</p:for-each>

For each matched /div/@a, the replacement expression "3+4" is evaluated,
producing 7 and the string value of @a becomes "7".

Makes sense.

Now consider:

<p:for-each>
  <p:variable name="opos" select="p:iteration-position()"/>
  <p:for-each>
    <p:iteration-source select="//div"/>
    <p:string-replace match="/div/@a">
      <p:with-option name="replace"
		     select="concat($opos,',',p:iteration-position())"/>
    </p:string-replace>
  </p:for-each>
</p:for-each>

This is the moral equivalent of (for the first iteration of each loop,
at least), replace="1,1"

If you evaluate "1,1" you get...a sequence of two 1's. That's either
an error or the result is @a="11" (or maybe "1 1").

Which of those is the right answer?

The poor, naive user probably expected @a="1,1". AFAICT, in order
to get that, he or she has to write:

<p:with-option name="replace"
        select="concat('&quot;',$opos,',',p:iteration-position(),'&quot;')"/>

which works, but seems surprising.

Did my analysis go off the rails somewhere?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Some people do their laundry in emacs,
http://nwalsh.com/            | but I find typing ^C-^X-^W-q-L-TT to
                              | add the fabric softener to be a bit
                              | cumbersome.-- rlr@panix.com