It's worth noting as well that CHECK and END blocks give the same results as we see in INIT. So in some way those portions of a program's lifespan are privileged. Also, whether the variables have attributes is incidental to whether peek_my can see them at runtime, for example,

{
    package Baz;
    my %baz;
}
[download]

likewise only shows up when dump_lex is called from the special execution blocks.

Now, a standalone my %quux is visible no matter where dump_lex is called from. This makes me think that perhaps there is loophole in PadWalker, and that there is still a way to keep your lexicals private; namely, by relying on perl's runtime enforcement of scope which I guess is just the same mechanism that makes it possible to write:

sub foo {
  my $foo;
    {
      my $foo;
    }
  }
[download]

That is to say, at runtime perl knows to differentiate the two $foos based upon where they are declared, despite being written on the same pad.

Update: Duh. This isn't a loophole, but rather the documented, intended behavior. From the docs: It will only show those variables which are in scope at the point of the call. I must have read that line 10 times and it only made sense when I was about to step in the shower :)