Decide on the specific purpose and function of each vault and allow each vault’s settings/plugins to evolve independently.
An example from my experience: I began with a single vault containing mostly a ZK. I started adding project management type capabilities to it. Since a ZK doesn’t lend itself to those types of things I needed a way to separate the concerns, so I started using folders. That eventually became a structure similar to PARA. But things still felt too tightly coupled. So I eventually moved all of my project notes out into a separate vault and physically separated the two concerns. Suddenly I found I no longer needed the PARA-type structure at all because using it was in fact an attempt to solve a problem incorrectly. By physically separating the two concerns they could become properly decoupled and evolve independently. The folder structure in both changed quickly to tailor down to each need, neither of which looks like PARA at all. And the plugin selection changed quickly as well. So did certain things like tag strategies. Items that I needed in one vault are completely unnecessary in the other. In my ZK I barely ever use tags but in my project vault I use tags all the time. Because it makes sense in that particular context and adds value.
So my overall point here is to think hard through the major functions of any vault you create, and try to group like concerns together and keep unlike concerns apart. Using URLs seems a good way to keep things loosely coupled between them when coupling may actually be needed.
Keep the coupling as loose as possible. Don’t have a workflow in one vault become overly reliant on the links or activity from another vault, and vice versa. You want to be able to adapt each vault independently. Let the URLs become a contract/interface between the concerns. Don’t tie functions too closely together between them. (this is a fundamental software design / systems design principle to enable parallel independent evolution of components, and it definitely applies here)
If you find many notes seem to span (be copied into) more than one vault then consider that as a signal that it may be best to create a new vault containing those notes and have the other vaults link to/from those notes instead of maintaining copies. (again, systems engineering refactoring concepts apply here)
There’s probably more but those seem like the big ideas off the top of my head. Avoid unnecessarily entangling concerns, keep like with like, communicate via standard pathways with standard protocols (i.e. the URLs) and enable independent parallel evolution of each vault.
