Thank you for spotting the bug.

Also, I am not sure that would work for the cases where the second argument is a string with a file handler embedded, as for instance open($fh, ">&STDOUT") or its three-args form open($fh, ">&", "STDOUT"). You will probably need to prefix those names with the calling package name.

Yes, true. It's actually more complicated than that. A lexical filehandle is made into a GLOB reference by open. But since that open() happens in FileHandle::Track, the associated symbol is generated using that package and the lexical filehandle variable:

package blorf;
open my $h,">","blorfldyick";
print $h,$/;
print *{$h},$/
__END__
GLOB(0xbf4e78)
*blorf::$h
[download]

I can see no way to circumvent that. Not that it matters much, because it doesn't matter to the lexical filehandle which holds the GLOB reference. It's just that e.g. Data::Dumper shows all filehandles as belonging to the FileHandle::Track package when dumping the hashref returned from get_fds... meh :-(

$VAR1 = {
  'GLOB(0x151ce78)' => {
    'fd' => \*{'FileHandle::Track::$_[...]'},
    'open' => 'GLOB(0x151ce78) > blorfldyick open main -e 1',
    'opentime' => '1491480967.655713'
  }
};
[download]