I'm still thinking a "stacked" exception might explain the behavior.
When an unrescued raise enters the exception handler, then the further
void assignment exception that you get with return never happens
because the interpreter is already in an exception context and simply
aborts before it sees the next exception (right side of assignment
evaluated first). But if the exception is rescued, the nil return from
raise is assigned (unless the value of the rescue is used, ala Kero's
example?). With return you simply break out of the context and leave
the assignment dangling, so you get the void assignment exception. That
seems to make sense...

Regards,
Jordan