I still like the idea that I think you originally had, whereby apps could only write to their own specific area, thus containing all their configuration. I think that would solve 99% of all complaints about the registry.
Right now, they can write to anywhere your user has access to.
What if an app provides COM services and needs to write that to a centralized location that is enumerated to discover available COM services?
What if your app happens to be a god-awful HP Print Center app with it's own print drivers and a Windows Service, where it needs to write to a central location that is enumerated for device drivers and Windows Services?
Then you have Microsoft Office/Plug-Ins/plugin-guid, whereby Plug-Ins is user writable
> What if an app provides COM services and needs to write that to a centralized location that is enumerated to discover available COM services?
If it is providing services it can write, if it enumerates it can read. You can also have multiple levels, like HKLM (machine) and HKLU (the user).
> What if your app happens to be a god-awful HP Print Center app with it's own print drivers and a Windows Service, where it needs to write to a central location that is enumerated for device drivers and Windows Services?
May God help you. No, but you would have, again like above, a central location you could write to. Up to the Admin if Joe can write to this location or only privileged processes.
It's just, a lot of this was not enforced, only partially (from the windows side when it looks for things), so for everyone else, it's a free for all.
The biggest disadvantage on the Linux side is that something like Group Policy is ridiculously difficult, because every app has it's own location and DSL, and sometimes you have one, central, config file, and sometimes the app is considerate with something like override.d.
2) COM discovery wasn't particularly well designed in the first place, IMO. It's a perfect example of where the keys should be explicitly tied to the owner (ie. the COM provider) so they are removed when the component is uninstalled. So many programs leave reams of COM-related entries behind, this is table stakes for all those free (and IMO not very useful) registry cleaners.
In both your second and third examples, the OS could either:
a) Provide specific API's (printing is a fairly common service where it makes sense to have a lot of shared functionality hosted in the OS).
b) Designate well-known locations where apps can share access to keys. This is loosely the case today, but I argue the OS could do more to make them explicit and maintain ownership ties so the relevant ones are automatically removed when appropriate (I think Windows Store moved in that direction??).
c) Require one app to own and gatekeep the centralized information, and provide simple primitives that allow the other apps to interact with it to register/unregister themselves. The expectation is the owning app actually manages said information (hopefully providing some sort of UI) but at least when it's removed so will all the contained info.
The important thing is that ownership policies are maintained so when a driver / COM service / etc. are removed their cruft goes away along with them. I recognize there are edge cases but I'm not convinced they can't be solved in a generalized, well-thought-out fashion.
Personally I don't feel an app's storage needs to be completely isolated as is done in Android (a security/extensibility tradeoff).
A lot of this housekeeping comes down to an OS maker providing out-of-the-box tooling to developers, along with sensible defaults, that make following good habits natural and friction-free.
Microsoft in particular provided tools and documentation since the early days, but relied too much on developers to follow them and didn't do enough to make it "just work" for the lazy ones.
Then over the years they changed their minds several times along the way, so convention became a sometimes-conflicting spaghetti mess.