I'm not sure about this named capture group proposal. The idea behind the proposal is that regexp engines parse using the old grammar, but if a GroupName is fou

I'm not sure about this named capture group proposal. The idea behind the proposal is that regexp engines parse using the old grammar, but if a GroupName is found, re-parse using a different grammar: If the result of parsing contains a GroupName, reparse with the goal symbol Pattern[~U, +N] and use this result instead. But "the result of parsing" by definition cannot contain a GroupName because GroupName is not part of the initial grammar. Furthermore it appears that the named capture group backreference syntax `\k<groupname>` is in fact valid under the "old" (no-named-capture-group) syntax. Thus the interpretation of `\k<groupname>` depends on the future parts of the expression, similarly to how `\3` can be an octal escape or a backreference depending on the rest of the expression. JS regexp parsing is already underspecified [1] and requires two passes to disambiguate backreferences from octal escapes. Now it appears we potentially need a third pass to disambiguate named capture groups. [1]: https://blogs.msdn.microsoft.com/ie/2010/08/25/chakra-interoperability-means-more-than-just-standards/ https://blogs.msdn.microsoft.com/ie/2010/08/25/chakra-intero...