the function of $regsubex(), as we all know, is to perform substitutions first then evaluate afterwards. this must have originally posed a problem:
$regsubex($chr(40), /(.)/g, $len(\1))
if substitutions were performed immediately, with no intermediate steps such as there now are, this would of course throw an error ("$len(()" -> invalid format). so, clearly something needs to be done to the substitution parameter before it gets passed to the interpreter to avoid double evaluations and other undesirable behaviour. we could suggest that a modification be made to the core evaluation function, such that any regsubex markers encountered as tokens will have their values resolved as appropriate. this way, for example, '$len(\1)' gets passed to the interpreter, and '\1', which would ordinarily be plaintext, would instead evaluate to the first backref.
this would solve the reported problem, but would require changes made to a core function which must already be massively complex. we can forgive Khaled for implementing it the way he has: no changes to the core function, and manipulating the substitution parameter in such a way that it can be passed to the existing evaluator and have it yield the correct output.
currently, regsubex markers are replaced from left to right as $1, $2, $3, etc. (with optional $+s to ensure correct output) and then the result is evaluated in an environment where each $N returns the value of the corresponding marker. this obviously stops any pre-existing $N in the substitution parm from evaluating correctly. in hindsight, we can groan about the limitations of this approach, but can we suggest a decent alternative? the truth is, there isn't really a much more sensible alternative that works with the current substitution model. obscure variable names? some hidden internal identifier that functions as $1- (eg. $`~(1) $`~(2)) :P?
there is, however, a solution that doesn't involve much of a change to Khaled's existing code. we know that he iterates through the substitution parm looking for markers such as \1, \2, \0, \a, \n, etc. and maps one marker to one $N. why not include any pre-existing $N in this mapping? for example:
//tokenize 32 x | $regsubex(abc, /(a)/, \1 - $1)
then for the substitution parm, \1 gets converted to $1 as usual, but this time it takes $1 in the parm and turns it into $2, then sets up the sub parm for evaluation in an environment where $1 = <value of \1> and $2 = <value of original $1>. ie:
//tokenize 32 x | $regsubex(abc, /(a)/, \1 - $1)
; set up substitution parm and have $1 = a, $2 = x
... /!returnex $1 - $2
if Khaled wants to fix this problem with little additional work, i think this is the most comfortable approach to doing so.
edit: just realized an obvious drawback of my proposal ;( the replacing of regsubex markers is clearly different than the evaluation of $N (or identifiers in general) in a line of code. currently, a substitution parm equal to 'a\1a' constitutes a use of \1, but 'a$2a' should be treated as plaintext and shouldn't be replaced by 'a $+ $1 $+ a'. so it wouldn't be a simple addon to the existing method, but still manageable. but then there's '$eval($2, 0)' which would get converted to '$eval($1, 0)' and evaluated to '$1'. yes, a similar problem arises presently with such things as:
//echo -a $regsubex(a, /a/, $eval(\1, 0))
but i suspect '$eval(<code with $N>, 0)' is more commonly used than '$eval(<code with regsubex markers>, 0)'
