It is not a theory.
A “small option” is rarely just a checkbox. Every sandbox option has to be wired into game prefs, UI, save data, multiplayer sync, server config, edge cases, testing, and future compatibility. That is exactly how minor-looking systems become long-term maintenance problems.
Rarely? I would say it is the other way round: The majority of the new sandbox options is not a new feature as well and needed only xml changes to work. And xml does need neither multiplayer sync (because it gets already synced no matter how new it is) nor a server config. It surely needs UI changes and testing, but I'll bet that whoever does UI and definitely wohever does testing is not the guy who is in charge of the networking code.
Examples: Almost all the loot abundancy options in "Resources", "temperature survival", "crafting max quality", ...
From the rest a lot of options seem to manipulate data that was probably already availabe as variables in the code and needed only some code to expose that variable into xml so they can be manipulated from there. Again not something that needs multiplayer code or the network guys in my estimation.
Examples: "Vehicle Self Damage", "Electrical Output",
A few options actually seem to add new functionality and those could actually have needed the same guys you want for bugfixing your network code.
Examples: "Smelter type", "Tiny Zombies" "Workstations in the Wild"
The "jar" situation is the clearest example. Something that sounds simple on the surface ended up costing TFP a major amount of development time and effectively set them back an entire alpha cycle. That is the kind of thing I am talking about.
But the jars were actually a minor new feature (not only an option) among many other features that came with V2.5. And we don't know how much time they cost because there were lots of other changes as well in that update.
I am not saying player requests are bad. I am saying the timing matters. When core systems are still throwing serious issues, adding more toggles and special-case sandbox options increases the test matrix and creates more places for things to break.
So no, I am not suggesting TFP is “forced” by votes like a congress seat count. I am saying that every added option has engineering cost, QA cost, support cost, and regression risk. My concern is that the current focus should stay on stabilizing the core systems before expanding the sandbox menu further.
And like Syphon583 said asking users about options doesn't necessarily mean they'll add more options but that they can add those options that were asked for the most. Like congress, the seat number remains the same, but more voters show a more accurate picture of what the public wants.
