It's not a side-effect. It's not a bug. local undefines its argument.

The documentation Temporary Values via local() says:

.... The argument list may be assigned to if desired, which allows you to initialize your local variables. (If no initializer is given for a particular variable, it is created with an undefined value.)

Taking the empirical approach:

  use strict ; use warnings ;

  our $fred = 78 ;

  { local $fred = $fred ? 'Was Defined' : '*undef*' ;
    print "\$fred = $fred\n" ;
  } ;

  print "\$fred = $fred\n" ;
[download]

  $fred = Was Defined
  $fred = 78

Were it not for the side effect of setting $SIG{ALRM} to undef, nobody would ever be able to tell that being set undef is apparently a step in the initialisation of the local. The implementation may assume it doesn't matter -- we live and learn !

IMO, this quacks like a bug.

The documentation Temporary Values via local() says

I agree. The docs are misleading. local actually does the same thing whether an assignment ("initializer") is present or not. local doesn't even know of the presence of an assignment. Similarly The assignment doesn't know local is present.

Were it not for the side effect of setting $SIG{ALRM} to undef, nobody would ever be able to tell that being set undef is apparently a step in the initialisation of the local.

Not so. I rely on that feature all the time.

sub d :lvalue {
   print("$_[0]: ", defined($_[1]) ? "[$_[1]]" : "undef", "\n");
   $_[1]
}

our $fred = 78;
d("pre local", $fred);
d("post local", local $fred);
[download]

gives

pre local: [78]
post local: undef
[download]

It can also be seen with an "initializer" present.

sub d :lvalue {
   print("$_[0]: ", defined($_[1]) ? "[$_[1]]" : "undef", "\n");
   $_[1]
}

our $fred = 78;
d("pre local", $fred);
d("post assign", d("post local", local $fred) = 90);
[download]

pre local: [78]
post local: undef
post assign: [90]
[download]