Odd? I think so. Consider that the current package is still recognized somewhat if you query it via something like B::svref_2object(sub{})->STASH->NAME. I gather that what you are actually looking for is what changes can be propogated via the symbol table back out of a Safe module. When I try to touch a global $Foo::foo within the Safe module I get a memory fault. The ->reval operation actually calls Opcode::_safe_call_sv which internally creates a new symbol table for the about-to-be executed code. Obviously if the code being executed has internal package statements then those will be respected. Is there something else you are trying to get at here that I'm missing?

BTW do a moment of 'use strict' on your code to fix your partially renamed $parsed / $code_str variable.

__SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;
[download]

I gather that what you are actually looking for is what changes can be propogated via the symbol table back out of a Safe module.

That's just it. So the fact that a new symbol table is used for the untrusted code is (at least partly) responsible for creating the sandbox. And that guarantees that whatever package statements are encountered won't violate the boundaries imposed by Safe. Well I think that's very good!

Thanks for your help diotalevi.