The user-defined context is the only route into the application state and can be as wide or narrow as you need. So you can share persistent state deliberately, e.g. by having that context contain a pointer to a db conn, but this is always a conscious, opt-in choice, and errors like accidental reuse should be impossible unless you're doing something inadvisable like using global variables.
In 99.9% of cases in web development you want the PHP model of doing things. The 0.1% case is the asynchronous background job, that can be solved, maybe not as elegant as in other languages, but why optimize the edge case?
So anything that needs to be processed asynchronously, like say, sending out a few dozen emails or notifications, I just publish the task to the queue and that other container handles them.
This could be simplified even further if you use a pubsub service that can post data to a url as it comes in. Thus allowing the single php container to asynchronously process the tasks all in their own individual threads.
This didn't work for me as Google cloud's pubsub seems to absolutely flood it's target with requests seemingly ignoring 503 or any other error code and not backing off until it has dos'ed your server.
That said, I'll gladly take the guarantees of a type checker in exchange for giving up the guarantees of statelessness. It would be nice if there were a stack that could give me both.