No, it's no real code, 'identifier' was meant as a generic name for the hash keys.
Making a small script isn't trivial since I gather the data to build the hash and the 'code'-array in several nested subroutines. I did a 'workaround' by now, which means I recoded stuff using more nested 'if'-constructs than in the stripped-down (but functional and error-producing) code below:

   for (my $y = 0; $y < $num; $y++) {
      for (my $x = $y+1; $x < $num; $x++) {
         if (($scores->[$y]->[$x] >= 0.96)) {
            if ($blast_par->{$cleancodes->[$x]}->{"taxon"} eq
                $blast_par->{$cleancodes->[$y]}->{"taxon"}) {
               if (($blast_par->{$cleancodes->[$y]}->{"defline"} =~ m/
+refseq/i) &&
                   ($blast_par->{$cleancodes->[$x]}->{"defline"} =~ m/
+refseq/i)) {
                  if ($blast_par->{$cleancodes->[$y]}->{"defline"} =~ 
+m/NP_/) { # this line produces the error
                     $to_keep = $y;
                     $to_kill = $x;
                  }
                  elsif (($blast_par->{$cleancodes->[$y]}->{"defline"}
+->[$y] !~ m/NP_/) &&
                         ($blast_par->{$cleancodes->[$x]}->{"defline"}
+->[$x] =~ m/NP_/)) {
                     $to_keep = $x;
                     $to_kill = $y;
                  }
               }
               &generic_sub($to_kill, $to_keep);
            }
         }
      }
   }
[download]

I think the error has something to do with the 'if'-lines not meeting the "... =~ m/NP_/" requirement. I split up the if's in a more simple (but also more inelegant ;-) manner and it works now. From Data::Dumper()-analysis the array and the hash itself are valid.
But anyway, I'd like to have a clear mind about what happened here to avoid such errors in future, so, if anyone's got an idea... ;-)

Micha