As you can't disable access to most of that stuff, you've got to share it and once you share it, you've got to protect it and still run the risk of ending up in an inconsistent state thanks to race conditions and lack of locks.

Why would there be any "lack of locks"? You're (wrongly) assuming that the only alternative to cloning, is direct, unfettered access. It isn't.

Just as the internal state of threads::shared variables are protected now, so would the single, shared copy of the currently-cloned, process global state be so protected. It would have to be, because it would live in exactly the same context, and would be accessed in exactly the same way.

That doesn't remove the need for user locks to protect user state, but it does preclude the user from having to protect Perl's internals state.

I do not think your blame of the fork emulation is correct.

I cannot help what you think.