I realize a lot of the ideas below have been posted above, but it makes for difficult reading for half of this to be “as [username] said”.
$HOME/.obsidian
This will be exactly the same as the current per-vault directory, however all plugins and themes which are installed from any vault will have the actual js/css/manifest stored here. There will also be a data.json here, which will use the same developer API as the current per-vault one, just via Plugin.saveGlobalData/Plugin.loadGlobalData instead of the existing ones (no breaking change is an added bonus).
Also no workspace.json or other vault-dependent fields.
$vault/.obsidian
This remains mostly unchanged. The main difference will be that the plugins directories contain only the data.json file. It would be nice for plugin devs to have access to a Plugin.loadMergedData rather than being required to do their own comparisons and object merges should they need to handle hierarchy, which would also reduce plugin bundle size and execution times.
Changing and loading settings
Could do a deep merge on the JSON with every change, could do that with some fancy caching to save execution time,
Probably best to load the global configs, then iterate the local ones and set those for this app session. This ties in with the point below about global-first settings.
Additionally, when a setting is changed, no matter if local or global, Obsidian can just do what it’s doing now and set it on the fly without additional processing.
For storing the settings then, a toggle at the top of the settings subwindow (and other subwindows within such as themes or plugins) can have a simple toggle at the top for switching between changing globally and changing locally.
I would argue this should default to global, and if you close the settings then open them again, it should reset to global. To edit settings locally should require opening settings, and clicking a toggle.
My reasoning for this is because every other piece of software I’ve come across has global-only settings. People are used to changing a setting and it applying for all uses of the app. It’s the same reason content scrolls vertically and double-tap is like; everyone knows how it works, so working in the same way reduces friction. If a user changes something locally, works for an hour, then decides to change a setting, they won’t necessarily recall that they’re in local mode, even with the activated toggle.
The toggle should be labelled of course, “global settings” when off, “vault settings” when on, and an on-hover/focus tooltip on that text briefly explaining what it’s for an a link to the relevant section in the docs.
This toggle’s status should be made available on Plugin.vaultSettingsMode so plugin developers can have a signal for when their plugin might want to use Plugin.saveData vs Plugin.saveGlobalData.
It’s been two and a half years since this feature request was opened.
If developer time is an issue, I’ll happily come in temp and implement this for you as quickly as possible (email me).
If it’s a design choice to continue to not have this feature, that’s frustrating for a lot of us.