Allowing the initial synchronization to not happen for joining players with Manual Sync scripts would give us the capability to assemble our own Wells for synced data. This establishes capability for syncing once with either a trusted player or a small number of players before choosing to locally propagate an assumption for all other players, including themselves. This completely mitigates cases where there must be "Some Trust" from absolutely "Zero Trust" security practices and flooding joining players with network traffic in larger instances.

As is PlayerObjects allow world devs to trust NetworkOwnership more than ever before. Juggled Network Ownership GameObjects in the past have had desyncs and also will always favor the longest playing player in an instance, even when that isn't ideal. That creates multiple cases to be accounted for and corrected after the fact. The key words there are "after the fact", which means any best effort is already potentially too late.

Also as is, we have Networking.GetOwner with PlayerObjects, which natively, synced data can only be updated via the owning player. This allows players currently in the instance to check access being granted before allowing an event to play out. This allows "Zero Trust" security practice to now exist with any isolated Access Control List that is either uploaded within a world or fetched with string loading. (Zero Trust here being no trust between players in the instance. Inherently, there must be an assumed trust with the parties hosting both VRChat and a source for any Access Control List.)

There, however, is a problem when there are late joining players with our existing capability. To mitigate an overhaul to the current NetworkOwnership defaulting case for longest playing players in an instance, adding capability to manage a Well system without overwhelming joining players is a great alternative.