Yeah, I don't understand having a warning for "my ... if 0;" but not for other "my ... if ...", especially since the second construct is more likely to be a real bug.

The warning for "my ... if 0;" should convey something along the lines of "stop doing that hack to get 'state' variables as we won't guarantee that it will continue to work". The warning for other "my ... if ...;" should convey "you've got a bug there; move the 'my' out from under the 'if'".

It is silly to warn for something that actually works fine but in theory might stop working some day while silently accepting something that just indicates a mistake (I've never seen code that intentionally and correctly used the behavior of "my ... if maybe();"), and a subtle mistake that is easy to not notice in testing. The second case is much more deserving of a warning.

This complains about uninitialized value (of course), but gives no warning in 5.14.0:

use warnings;
use strict;

use constant duh => 0;
my $y = "X"   if duh;
sub x{ 
    print $y ? 'Okay' : 'bad';
}

x();
print "$y\n";
[download]

And no warning even for this:

use warnings;
use strict;

my $y = "X"   if 0;
sub x{ 
    print $y ? 'Okay' : 'bad';
}

x();
print "$y\n";
[download]

Yeah, it only warns on my $var if 0, not on my $var = EXPR if COND. I do not know why.

To allow stuff like the following?

print(my $x = 1234) if COND;
[download]

Which is to say, they probably didn't want to step on anything that has remote chance of being legit.

That was a hack for getting state variables. So it might be found in code that should use state instead, and won't work as expected in the new versions.