Whether you do this in separate files or not should be based on other considerations than turning them off or not. Largely based on two criteria:
- mitigate risk of file corruption
- take advantage of the FMS backup efficiency
Also: "step back" seems to imply that the only good way to develop a solution is by putting all tables and modules in one file. That's simply not true.
Sure there are a lot of threads talking about this topic, and the number of other consideration to take… the + and the -.
My first opinion is, Yeah, this is one hard but passionning topic !
An example : a very popular purpose of multiple file solution called Separation model, is to separate Data (Tables) form UI (Layout, Scripts, etc…) and often, implies that if could facilitate updates of existing solutions. And frankly, it is sometime even seen as a remedy to the main "no go" discussed about FileMaker against other platforms : monolithic database file. Personnally, I never tried multiple file solution this way, and i am definitely perplexed. If i agree Scripts and Layouts are major part of development job, but hey, what about table and fields, their calculation's formulas, TO and relationships graph ! For my projects, I just cannot imagine an update with only changes on a UI file. Unlucky i am ?
The other example, Modular Solutions, i can much better understand the advantages : simpler Relationship graphs, simpler UI and in particular navigation, and of course Wim's hint about backup is particularly interesting. Note this one was far more obvious when externally stored containers didn't exist.
As Fred(CH) mentioned, implementing a separation model of some sort, whether it be do divided UI from Data or to split up your solution by modules, requires quite a bit of forethought and pre-planning as to how you can provide all of the functionality updates you could possibly think of [and those you haven't yet imagined] down the road without having to replace all of the files.
Although admittedly challenging, I believe it can be accomplished in certain circumstances, but probably not in all circumstances.
For your approach to work, every module would have to be entirely self-reliant and fully functional on its own right [script triggers and UI included]. That would be the best [and probably the only] way in which you could "swap out" or turn modules on/off without breaking the whole thing.