I think some behavior in Perl hash usage has changed. It used to be that $hash{test_elem} would set that hash key to a value of '' (empty string).

How would you know it no longer does that? Your code doesn't demonstrate this. (I see the Dumper now)

That said, it's true that Perl doesn't do that, and I doubt it ever did. Here's how Perl behaves:

• When $hash{test_elem} is used as an rvalue, it doesn't modify the hash.

  $ perl -wle'my $x = $hash{test_elem}; print keys %hash'
  [download]

• When $hash{test_elem} is used as an lvalue, the element must exists, so it's created. Like other variables, it starts up undefined.

  $ perl -wle'my $r = \$hash{test_elem}; print keys %hash; print defined
  +($hash{test_elem})?1:0;'
  test_elem
  0
  
  $ perl -wle'1 for $hash{test_elem}; print keys %hash; print defined($h
  +ash{test_elem})?1:0;'
  test_elem
  0
  [download]

  There's special code in place to avoid creating the element unless necessary when passed to a sub.

  $ perl -wle'sub {}->($hash{test_elem}); print keys %hash'
  
  
  $ perl -wle'sub { $_[0]=1; }->($hash{test_elem}); print keys %hash'
  test_elem
  [download]

• If you dereference an undef scalar (including a hash value), autovivification will create a variable of the appropriate type and store a reference to it in the scalar.

  $ perl -wle'my $r; $r->{x}; print $r;'
  Useless use of hash element in void context at -e line 1.
  HASH(0x816c158)
  [download]

In no case does Perl assign an empty string to a scalar. Undef does resemble the empty string, but not in Dumper's output.