I don't see why this should be an error. Just as

my $x = 5 if $t;
[download]

could be semantically equivalent to

my $x; $x = 5 if $t;
[download]

I think it all boils down to a matter of personal interpretation and taste; your example doesn't convince me at all: yes, it could, but I see no reason why it should. More precisely, it's true that the single

my $x = 5;
[download]

statement is semantically equivalent to the two

my $x;
$x = 5;
[download]

statements. But is it true in general than when STATEMENT is equivalent to STATEMENT1; STATEMENT2; ... STATEMENTn; then also

STATEMENT if condition;
[download]

is equivalent to

STATEMENT1;
STATEMENT2;
...
STATEMENTn if condition;  # ?!?
[download]

IMHO not only is the answer no but FWIW I see no aesthetical appeal of such an "algebraic" property.

OTOH since

STATEMENT if condition;
[download]

is generally equivalent to

if (condition) { STATEMENT }
[download]

and

if ($t) { my $x = 5 }
[download]

is perfectly valid, albeit fundamentally useless, perhaps the "incriminated" construct should not trigger an error, but just be a happily useless thingy. Granted, Perl 5 already has so many ad hoc deviations from orthogonality for the sake of beauty, pragmatics and magic that one may want to throw in yet another one: yet I still fail to see how that particular construct could be of any good with any of those.

I see no reason why it should

Well, (a) because nobody has offered any other workable semantics for it, and (b) because it's what some programmers expect it to mean anyway.

when STATEMENT is equivalent to STATEMENT1; STATEMENT2;

But that will always break down with statement modifiers, even in cases not involving a combination of compile-time and run-time actions.

A word spoken in Mind will reach its own level, in the objective world, by its own weight

I see no reason why it should

Well, (a) because nobody has offered any other workable semantics for it, and (b) because it's what some programmers expect it to mean anyway.

Well...

1. there's the noop semantics which at least has the advantage of being consistent;
2. this is a non sequitur: I would accept the reasoning if the vast majority of them did, but do they?

As far as the first point is concerned... why should that have a semantics at all? That is, why should it be valid syntax? (Exactly my point!) Really, quite a lot of things are not. One that springs to mind and may be somewhat related is the ability to define an aggregate and populate a slice of it in a single statement. Indeed the question why

my @foo{@bar}=@baz;
[download]

"does not work" is sometimes asked, even if not terribly often. The semantics is intuitive here:

my %foo; @foo{@bar}=@baz;
[download]

But then again, you never declare a slice, only scalars and aggregates as a whole. There's a logic in this. Parsing issues apart and however appealing it may seem to have another way to save some keystrokes, implementing that syntax would go by and large against any logic. Similarly in the situation we're discussing.

As for the second point: before reading your post, I wouldn't have imagined it. Maybe that's just me, but I'm sure it wouldn't be intuitively obvious to all. To me, it's just ugly: I wouldn't struggle to have valid syntax with that semantics for a construct that is not particularly useful anyway.

when STATEMENT is equivalent to STATEMENT1; STATEMENT2;

But that will always break down with statement modifiers, even in cases not involving a combination of compile-time and run-time actions.

Indeed. But then why should the behaviour be different in cases involving such a combination?!? I would just say: one more reason for not wanting to mess with it.