Thank you for pointing out Readonly. I will certainly have a look at it, and using & is a good suggestion too. However, the quote from perldoc,

Unary "+" has no effect whatsoever, even on strings.

does IMHO not explain the observed behaviour. Note that the decision of whether or not the lhs of => is taken as expression, depends (according to the docs) on whether or not it is a bareword. This is a purely syntactical issue and does not take into account what an operator does. We have +BIRD to the left of =>, and this is certainly not a bareword.

If your interpretation of the perldoc is correct, the compiler's reasoning would go along the following line: "Hmmmm, we have +BIRD. I have no idea what BIRD is (haven't decided yet), but no matter what it is, + won't change it anyway, so just throw it away. This leaves us now with BIRD=>...., so now to the left of => we have a bareword; OK, let's quote it".

I feel that this would be a very strange approach to compiling. Kind of: Evaluating unary + very early (because it is trivial to evaluate), and keep the other operators for later (because their interpretation depends on the context).

Update: I would like to add that an unary + does work when it comes to access the element of a hash. For example, $x->{+BIRD}substitutes the constant BIRD. If your interpretation of perldoc would be correct, this expression should be treated equivalent to $x->{BIRD}, but (and IMO correctly), only in the latter case is BIRD taken as the string BIRD.