>> Building 29 separate settings with confusing and overlapping effects is less work than making a single setting of: [Local Only]?

Yes, absolutely. 29 separate overlapping settings likely match up precisely to arguments in various APIs that are used. On the other hand, what does local only even mean? No wifi? No hardwired connection? LAN only? Connection to the internet for system updates but not marketplace? Something else? All with a specified outcome that requires different implementation depending on hardware version and needs to be tweaked everytime dependencies change.

Having a separate setting for unconditionally disabling all wireless communication would be helpful. The other stuff you mention can be separate settings if it is useful to have them. (A setting to unconditionally all disable wired connections is less important since you can just avoid connecting it.)

>>what does local only even mean?

Let's start with this: Design the architecture so the core system works fine locally. Features requiring Internet connection are in separate modules, so they can be easily turned on/off, and designed so they are still primarily local.

E.g., store all current status locally and if requested another module sends it to the cloud, instead of cloud-first.

E.g.2, install updates by making a pull of all resources and then doing the update instead of requiring continuous communication.

Allow user control with options to completely shut off, whitelist, blacklist, etc.

Simple design decisions up front to make a software package meeting the user's local needs first, THEN allowing controlled access to the internet, under the USERS' control, instead of designing every feature to contact your servers first and compromising both usability and control at every step.