Perl is not as different as you suggest.

You are of course correct that Perl "bytecode" can be saved and restored (with some limitations), and taken individually, I agree with many of the statements you've made and they are useful additional information. However, in the context of this thread, and because it appears you're presenting them as a counterpoint to what I was saying, I have to strongly disagree.

the Perl virtual machine (PVM)

I've never heard the term PVM before and it is used nowhere in the Perl core or documentation. You'll find only a single reference in the Camel: "the Perl virtual machine (which we refuse to call a PVM)".

In theory, the PVM could be implemented in hardware.

In theory, any piece of software could be implemented in hardware.

The optimized C backend attempts to de-compile the Perl ops and operands into C code.

I think "attempts" is a key word here. Although I admit I haven't worked with this C backend, I am also not aware of any implementation of compiled Perl that is able to do everything that perl can.

If a Perl program is written to have no "run time side effects" at compile time

In other words, if I omit exactly those dynamic features that I was making a point of, then I no longer have a point :-P You also make no mention of eval, which is quite significant here as well.

If I compile a C program, the binary it generates is entirely independent from the compiler, it can be copied onto a machine with no compiler at all, and it is executed directly by the hardware. Perl code is executed by its interpreter, which runs alongside the compiler, so the Perl compiler has the ability to reach directly into the interpreter, and the Perl interpreter has the ability to directly reach into the compiler, simply because it is always there. Of course, in theory it's possible to link a C compiler into a C program, and maybe it's possible to have dynamically compiled C interact seamlessly with previously compiled and currently running C code, and maybe it's possible to have C code affect the complication phase of the surrounding C code, but at some point, I could just as well link perl, lua, python, etc. into my C program.

To bring this back into the context of the thread: how the compiler and interpreter interact in regards to declarations. Consider this example:

Foo.pm:

package Foo;
use warnings;
use strict;
use Exporter 'import';
our @EXPORT = qw/foo $FOO/;
sub foo { print @_, "\n" }
our $FOO = 'bar';
[download]

test.pl:

use warnings;
use strict;
use Foo;
foo $FOO;
[download]

In test.pl, strict is enabled and I make no prior mention of the function foo or the variable $FOO, yet I am able to use them. This is because use Foo; is essentially equivalent to BEGIN { eval ... } - during the compilation phase of test.pl, perl loaded another file, compiled it, executed it all the way through, and this execution of Foo.pm affected the further compile time phase of test.pl, allowing the compiler to distinguish that both foo and $FOO are valid here.

Taking it a step further:

use warnings;
use strict;
eval( rand() < 0.5
    ? q{ sub foo { print "Hello!\n" } sub quz { print "Quz!\n" } }
    : q{ sub foo { print "Perl!\n"  } sub baz { print "Baz!\n" } } );
foo(); # will it print "Hello!" or "Perl!" ?
quz(); # will it die or won't it?
[download]

I maintain that this is fundamentally different from how C and similarly compiled languages operate.

Update: Minor edits to wording.