I forgot to add an important point. If a coroutine can be started with its own separate Globals state, this means there is a technical possibility to safely run coroutines in applications with global state, guaranteeing they won’t break anything.
If the rule of having zero Globals becomes the default rule for starting coroutines, it makes PHP potentially less dangerous. It means that data can be passed into a coroutine only explicitly at creation time, and in no other way. Of course, we need to consider the potential performance impact of this logic. But if the performance drop is minimal, this feature could potentially make the language better and essentially turn PHP into a language where global state doesn’t exist at all. \ After all, any code is code running inside a coroutine. That means `$GLOBALS` effectively no longer exists. Memory is always localized to the execution context. This property potentially allows coroutines to be moved between threads in the future, because the memory model begins to look like an isolated region that belongs to the coroutine. At the same time, this property **does not break existing code**, because everything remains 100% functional inside a coroutine. But now we gain the ability to run multiple instances of WordPress in a single PHP thread, if we adjust the startup code. All of this resembles Erlang and sounds a bit crazy for a PHP developer, but so far I haven’t been able to come up with a counterexample that would make this property negative. Let me repeat the conclusions: 1. Each coroutine has its own GLOBALS/Static, and a developer cannot pass global state into a coroutine. 2. This forces the developer to pass objects explicitly, because there are simply no other mechanisms available. 3. `static` caching breaks for coroutines. But since coroutines don’t currently exist, this is not a problem. Developers will just need to account for it.
