Someone has to write code to make any protocol update work. The issue with Ghostnet++/Zombienet/Permanent Mondaynet is that you have to spend time writing migrations between random states of the code for no good reason. It would be a bad allocation of engineering resources and a great way to lose your sanity 
The primary audience of ghostnet are NFT/DeFi app devs who want a stable testnet against which to test changes to their own platforms. They typically rely on libraries and indexers to interact with the chain. The teams behind these libraries and indexers are the first responders to any proto breakage, it’s their job to smooth it out for the upper layers.
Indexer/library teams can tolerate regular chain restarts. Right now on the teztnets platform we have a rudimentary way of injecting contracts at genesis. You can then run checks on this contracts each time the chain reinitializes. Actually Taquito authors at ECAD are doing just that and caught a regression.
We want to improve this and get more testing on Mondaynet. Indexer support would come a long way as well.
(I don’t understand why the upgrade needs to be centralized either but let’s discuss one thing at a time.)
@rafoo An in-band signal is better than out-of-band. We just updated ghostnet from ithaca to jakarta with an user-activated update and it was messy: some bakers inevitably fail to apply the update and the network partitions, with nodes banning each other, and logs start screaming. Plus, if they don’t do it on time, the storage is non-recoverable and you have to resync the node.
And we don’t even have tooling for such an out-of-band signal: we have tezos-node config update --network <url> but it has to be run again for every new update. Hard-coding the upgrade block in the software is also slow and lossy.
A protocol level signal has a guarantee of delivery and simplifies node operations a great deal: just keep the software up-to-date. And in the latest iteration of the code, we can even cancel an upgrade before it kicks in and submit another one if needed. So from an operational point of view, it’s perfect.
There is a FAQ in the tzip that addresses this point in more detail.
have any bakers setup full fledged bakers on ghostnet, just like mainnet, paying out delegation rewards? Had a quick look at TzKT and it doesn’t look like any baker has provided the info to be picked up as a “Public Baker” on Ghostnet yet
I like the idea. This seems like a good opportunity to revive the baker registry.
