>> If you really thing the n/N distinction is confusing, what about a
>> "currying" mechanism whereby regexes automatically create their prebuilt
>> form and save it in an internal macro which is used for subsequent calls
>> to the same regex?
> AS you say, I don't think removing stuff is the right way forward at
> this point. The reason for raising this was to be clear that the current
> approach is the best one. Having a set of n/N functions does seem to
> require quite a lot of variants in the documentation, so I wanted to be
> clear that this is best.
> As Will says, an alternative is simply to save all regexes
> automatically, and check for the existence of the regex before building
> it. That of course costs in terms of macros, so the question is how many
> regexes are likely to be used. (We are talking about a typesetting
> system, so really this should not normally be 100s.)
You guys are right. I'll add this automatic storage this weekend, and
remove the N variants (since they will be done automatically).