My point is that there is a tradeoff. Remember my point was that if this is to be officially supported then perhaps nested vaults should be made a first class feature, with a section in the sidebar showing the “tree” of nested vaults as a superset of the folder browser. You could expand/collapse vaults from the parent, and (for example) double click a vault to “zoom in” so it appears to be the only open vault. (with presumably a “back” button to “zoom out” back to the parent)
Assume you have one parent vault P and two child vaults C1 and C2. Assume there is a component in the sidebar that allows you to switch views between P, C1, and C2. When in P you can see all content for C1 and C2, but when “zoomed in” to C1 you can only see C1, and same for C2.
When you are in P and install a plugin, is it installed in only P, or is it installed in C1 and C2 also? If it is in P only and then you “zoom in” on either C1 or C2 (e.g. by double-clicking one of them in the sidebar) then you lose access to that plugin because it isn’t installed in C1 or C2. This creates inconsistent behavior – imagine the UX complaints if you have different themes and “I double clicked a vault and Obsidian lost all my colors!” etc.
But if it is also installed in C1 or C2 then you lose the ability to operate them independently as I described before, because every plugin you install in P is forcibly installed in both C1 and C2.