We scripters are anticipating that eventually our scripts will be able to talk to outside web servers and thus solve the problem of persisting data longer term. Scenes are intrinsically designed to shut down and be cleared from memory when nobody has visited them for a little while, which means all data they accumulate over time gets lost. Being able to offload data to a web server for longer term storage is an obvious answer.
But this comes with a thorny problem I think we should discuss before we get this capability. Namely, we know a scene can be loaded up into multiple instances at the same time, mainly to accommodate large crowds by splitting them up. But this means our scripts, talking to web servers, will run into logical contradictions. In a winner-take-all game running on two instances, there would be two different winners, for example. The web application storing information about the game needs to keep track of the different game instances, even if they are going on at the same time in the same scene and even with some of the same players (since we can log in multiple times).
Let's talk about some of the hazards and tactics we might use to keep everything straight so we don't all have to solve these problems separately when we get this capability.