This seems like a parse error, but it's hard to say that the current behavior isn't intentional. Here are a few similar snippets, and how they deparse with -MO=Deparse,x9:

use strict;
use warnings;

my $pic = 1;
my $v = {R3R3_1_IF => 100};

print "Hello world. $v->{R3R3_$pic\_IF}\n";
[download]

The output with perl -MO=Deparse,x9 mytest.pl:

Backslash found where operator expected at mytest.pl line 9, near "$pi
+c\"
    (Missing operator before \?)
Bareword "_IF" not allowed while "strict subs" in use at mytest.pl lin
+e 9.
mytest.pl had compilation errors.
use warnings;
use strict;
my $pic = 1;
my $v = {'R3R3_1_IF', 100};
print "Hello world. $$v{$pic->R3R3_(\'_IF')}\n";
[download]

If you attempt to disambiguate using curly braces it still fails:

use strict;
use warnings;

my $pic = 1;
my $v = {R3R3_1_IF => 100};

print "Hello world. $v->{R3R3_${pic}_IF}\n";
[download]

The output...

Bareword found where operator expected at mytest.pl line 9, near "${pi
+c}_IF"
    (Missing operator before _IF?)
Bareword "_IF" not allowed while "strict subs" in use at mytest.pl lin
+e 9.
mytest.pl had compilation errors.
use warnings;
use strict;
my $pic = 1;
my $v = {'R3R3_1_IF', 100};
print "Hello world. $$v{$pic->R3R3_('_IF')}\n";
[download]

In both cases the interesting deparse to me is $pic->R3R3_('_IF'), and the explanation appears to be that the parser seems to feel this is a fine time to see the construct as indirect object notation.