I just totally disagree.
I think there's a technical reason / limitation that $N is used internally during regex
I'm really curious, what would be the limit or the technical reason that would make Khaled use the internal data of $N for \N, instead of another "internal data" ?
It might involve a lot more code complexity and introduce more bugs, simply to add a small extra convenience
If the actual implementation use $N and is working, where is the complexity, and why would it introduces more bugs ?
I also don't see what's so bad about the "workarounds".
Using the [ ] isn't an option since it would double evaluate the content (and working around that problem itself would make the code very ugly), same for the variable way, it's cool if you use $1 once, but if you use $1 $2 $3 $4 $N you have to create $N variable, not really a problem, but having to use a workaround here mean that there's a problem somewhere with the actual implementation, it is what is so bad.
I actually see this as a feature
What is the feature exactly, losing the previous tokenization ? There's already \N to get the matches, why would you use $N or see $N here as a feature ? How is that comparable to $v1 and $v2 ? It's completely normal to have a new value for $v1 and $v2 after each if statement, it's not normal at all to have $N being the same as \N in that case. The $findfile example is also not comparable, you can retreive the value of the previous tokenization inside the command parameter and still get the path too, (it is clearly stated in the help file that $1- will be filled with the path anyway, but using an identifier as the first token will make $N avalaible, and $!N will return the path)
