The red and green blocks are not that nicely separated, the red stuff becomes part of the base, and its information gets spread throughout the green block.
So this basically means that at the current state it could really be very hard to remove newGRF packages from a running game.
Not only remove is tricky, any form of change is tricky.
- Updating a newgrf (eg to a new version) means that some of the red data is modified. What is not modified however are derived values (that is, values that are computed from the red data)
- Adding a newgrf may de-activate other newgrf or base data. As such 'adding' is equivalent to 'remove', even though they feel like totally different operations.
One weird thing that happened when I tried out adding newGRF in a running game with scenario_developer switch turned on, is this one: No matter which newGRF I add, the first thing I notice is that the option to build electrified rails disappears. Thats weird. But I would like to know how such a thing can happen in the first place. This rather seems to me like a weird architecture instead of logical results when the Idea is to let packages add content to the game.
It means your idea of "add content" is wrong.
NewGRF is not about adding content, it gets assimilated into the base. There is no distinction between 'base' and 'addon' internally. As such the 'red' blocks don't exist, the base just grows a bit and soaks up the red blocks completely.
We considered making a better separation, but building a wall between base and newgrfs means that every access needs to go through that wall, which would kill performance (even today without wall, getting images from a newgrf is already a problem, see FS#4934). In addition, NewGRFs are so powerful that the effort would fail due to the incredible complexity, or you'd have to drop some NewGRF functionality. The latter of course means some NewGRFs don't work any more.
So, the only way out to get a robust/stable program was to drop the ability to change the world while playing. For some reason however, users refuse to accept that limit (unlike the zillion other limits that the program has), and abuse developer settings.
/edit: Oh wait, I forgot. newGRF not only enables openttd to add content to the game, but even alter it. Could that be a rule which allows these results to be valid?
Indeed, your idea of 'add' is dead wrong. There is no 'add' or 'remove' or so. The best you can do is "change", and a change can cause basically anything.
There are no simple rules to decide whether some NewGRF change will fail or not. When you see it failing immediately is the lucky case. If things do seem to work at first, deep down you may have messed up some data that spreads slowly, and later in the game surfaces.
A little off-topic but for me pretty important: What really impresses me, is the multiplayer performance of the game even in large maps with many clients. Do you have a documentary about the networking architecture so that I could have a look into it?
Basically, every machine computes the next state locally, so only speed of progress needs to be synchronized, and actions that are performed by the users have to be distributed to all clients. Afaik there is no documentation on it other than the source code.