Autovivification is a little underdocumented, IMHO. The Camel generally only talks about autovivification in three circumstances: for file/dirhandles, references, and/or lvalue context. I don't believe defined provides lvalue context, and // does not, and you're working with a plain hash, not a reference, so I think that none of the three circumstances really apply. Also, even with autovivification in play, my $r; print $r->{x}; causes $r to become a hash reference, but the key does not spring into existence. In this node, dave_the_m even explained how hash accesses in subroutine arguments are special-cased not to autovivify, despite the lvalue context.

So despite the absense of clear specifications, I believe the examples you showed are safe, and because Perl is known for its backward compatibility, I would be very surprised (and somewhat worried) if a future version of Perl were to change this, and I think it'd probably break a lot of existing code. Personally, I expect simply checking a hash key to not autovivify - but again, only outside of an lvalue context, and only as the last element in a chain of dereferencing, if any.

(One option if you have doubts and want to protect against future changes and code super defensively: just stick this line at the top of your script: { my %x; die if defined $x{y}; die if keys %x } # verify that autovificiation behavior hasn't changed.)