Unexpected parsing

JadeNB has asked for the wisdom of the Perl Monks concerning the following question:

After reading Conditional Operator, and delighting in the potential for unreadable code coming from using a conditional operator as an lvalue, I wondered how far in advance the lvalues have to be declared.

Huh? Well, we know that

my ( $c, $d );
1 ? $c : $d = 'Hi';
[download]

is the same (to B::Deparse) as

my ( $c, $d );
$c = 'Hi';
[download]

but what if you don't want to declare the variables in advance? Well,

my $d;
1 ? my $c : $d = 'Hi';
[download]

is the same as

my $d;
my $c = 'Hi';
[download]

In the other direction, here's a strict-safe program that B::Deparse makes non-strict-safe:

$ perl -MO=Deparse -e 'my $c; 1 ? $c : my $d; $d'
my $c;
$c;
$d;
-e syntax OK
[download]

^*. How about if we declare both variables in the conditional?

$ perl -e '1 ? my $c : my $d'
Invalid separator character '$' in attribute list at -e line 1, near "
+$c : my "
Execution of -e aborted due to compilation errors.
[download]

Now, maybe there's some reason that parsing : my $d as an attribute list is good, or at least expected; but I can't see why 1 ? my $c : my $d would be parsed that way, but 1 ? my $c : $d wouldn't. Would somemonk enlighten me?

UPDATE: ^* Notice that B::Deparse changes the semantics here (but I guess there's always the disclaimer that that might happen). For example,

our $d = 'Out';
{
    1 ? 0 : my $d;
    $d = 'In';
}
say $d;
[download]

prints Out, but is converted by B::Deparse into

our $d = 'Out';
{
    '???';
    $d = 'In';
}
say $d;
[download]

which prints In.
UPDATE: Oh, maybe it's that a colon followed by whitespace and an alphanumeric is always interpreted as the beginning of an attribute list, even if we're waiting for the interstitial colon of a conditional operator. Is this correct? If so, is it the desired behaviour? If so, should the precedence table in perlop be changed to reflect it?

Back to Seekers of Perl Wisdom