It doesn't matter. Hash keys are stored internally only once, even if they are used across multiple hashes. So though it may seem wasteful to have two hashes with the same key in them, it's not. The same goes for multiple rows of anonymous hashes with the same keys. This is an internal, automatic, and invisible optimization, but a smart one at that.

Update: For the record and posterity, I wanted to mention that this optimization is known as "Shared strings", and is discussed in Advanced Perl Programming (the Cougar book), published by O'Reilly & Associates. Find it in Chapter 20: Perl Internals, Section 3.3.1. The exact quote is:

To prevent unnecessary duplication, the actual key strings are maintained in a systemwide shared string table (strtab in strtab.h). strtab is a simplified HV: each value here keeps a reference count of the number of uses of that string.

It's also discussed in http://www.faqs.org/docs/perl5int, where Simon Cozens writes the following in section 4.2.2.2:

The HEK stored inside a hash entry represents the key: it contains the hash value and the key itself. It's stored separately so that Perl can share identical keys between different hashes - this saves memory and also saves time calcu.llating the hash value.

Neither of those sources are as ubiquitous as a POD reference, but aside from unraveling the source, they seem to be the best insight we've got on the topic.