I wouldn't call it a change because eval blocks can have return statements in 5.8.8 as well which is where this "issue" (call it what you will) was found. I use returns in eval blocks all the time, in this idiom:

<c>eval { 
   ... something that can die ...
   #insures we never go into the do block except when we die
   return 1;
} or do { 
  my $e=$@;  #the exception
  ... exception handling here ...
};
[download]

That odd bit of code is needed because destructors can clear $@ so there are times when a routine dies but $@ is undefined or ''. On the otherhand, an eval block is guarenteed to return undef if it dies an unnatural death. Thus with the above idiom we can be sure that we will enter the do block if and only if the eval block dies before its time.

I would probably add the disappearing exception ($@ being cleared) to my list of odd and hard to track down bugs. It is easy to overlook it as a possiblity unless of course you are "in the know" that such things like disappearing exceptions can happen. Most tutorials on exceptions teach people to capture failure like this eval {...}; if ($@) {...} but if you use that idiom, the exception handling code will never be reached should something wipe out $@.

Apparently, as of 5.10, an eval block can have a return statement as well.

As ELISHEVA notes, this was possible before 5.10, too. From the 5.8.8 eval doc:

"In both forms, the value returned is the value of the last expression evaluated inside the mini-program; a return statement may be also used, just as with subroutines. The expression providing the return value is evaluated in void, scalar, or list context, depending on the context of the eval itself."