The named captures (or resulting hashes) do not have a relation to the actual position of the place where the group is defined. I think the whole intend of the module has a different purpose and I doubt the developer had group position in mind.

In the example that follows the results in this particular case foo and bar come from two different groups. How do you expect to get a position for that named group?

use strict ;
use warnings ;
use Data::Dumper ;
my $str = "abcdef" ;
$str =~ /(?<foo>[ab])*(?<bar>c)(?<foo>d)(?<bar>[ef]*)/ ;
print Dumper(\%-) ;
[download]

$VAR1 = {
          'foo' => [
                     'b',
                     'd'
                   ],
          'bar' => [
                     'c',
                     'ef'
                   ]
        };
[download]

> How do you expect to get a position for that named group?

by associating a named capture to an capture index. The word tie implies that this is done somewhere.

 
$VAR1 = {
          'foo' => [
                     'b',   # $1
                     'd'    # $3
                   ],
          'bar' => [
                     'c',   # $2
                     'ef'   # $4
                   ]
        };
[download]

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

I tried to look into Tie::Hash::NamedCapture, the "Pragmatic Module" used to implement %+ and %- but stopped at the XS barrier

I looked at this as well, specifically at FIRSTKEY and NEXTKEY in NamedCapture.xs, because I was hoping that maybe the iteration order would be the same as the order of the capture groups, but sadly that doesn't seem to be the case. Anyway, its implementation appears to use named_buff_iter in regcomp.c, and the central function here appears to be reg_named_buff_nextkey. But that's as far as I've gotten in my research, my understanding of the internals isn't good enough to see if there's an "easy" way to access the capture group name to number mapping.