Does a duplicate name imply a duplicate CapturingGroupNumber?

[msaboff]

The current spec ties the group number (aka ParenIndex) to the GroupName through the abstract operation CountLeftCapturingParensBefore. What semantics to you propose for ParenIndex wrt subsequent instances of a duplicate GroupName? I could see two possibilities:

1. Sever the one to one relationship between a GroupName and a unique GroupNumber as counted left to right. Instead ParenIndex is counted left to right. This could allow a developer to determine which of the named groups matched. It does however add semantic confusion.
2. Maintain the one to one relationship between a GroupName and a unique GroupNumber. Since GroupNumber is called ParenIndex in the spec, the name is no longer a good description and there would be holes in which ParenIndex's are valid. This begs the question as to whether ParenIndex's would be compressed and what to assign to NcapturingParens. e.g. would
   /(?<day>[0-9]{1,2})-(?<month>1[0-2]|[1-9]_-(?<year>[1-9][0-9]{0,3})|(?<month>1[0-2]|[1-9])/(?<day>[0-9]{1,2})/(?<year>[1-9][0-9]{0,3})/u
   have three or six NcapturingParens and is the ParenIndex for "day" always 1?

[bakkot]

The spec text in the draft PR takes the first option. I think this is less confusing than it would be to make it so that you can no longer determine group numbers by just counting left-to-right.

In practice, I've generally found people tend not to mix group numbers and group names, so it's probably not terribly confusing either way.

[nicolo-ribaudo]

Another point in favor of the current behavior is that it makes refactoring a regexp to add named capturing groups safer: if two groups with the same name had the same index, then it would break its consumers because it would change the result of .match.

[bakkot]

This proposal advanced to stage 3 with the behavior specified to be the first option above.