There are a lot of problems with software "shotgunning" their junk across the system. This isn't exclusive to the Registry or even a specific OS unfortunately. Just go look at what configuration files are located between applications on Linux for example, it is not consistent at all.
I'm not knowledgeable enough to know why a culturally enforced folder is far worse than the database that Windows has. Care to enlighten me?
"ProgramData" is like /Library.
"Program Files" is like /Applications.
I would put that in the same directory as the executable so I can have more than one executable of the same program or the path is simply passed as a command line parameter in the systems unit file.
Compare that to hardcoding the registry key path in the executable...
They're multi-user Operating Systems. Each user needs their own.
Storing .INI files in the .EXE's directory has been a no-no for many years, and nobody should be arguing for that. But the central registry concept makes even less sense. Use .INIs in your format of choice, and store them in the appropriate user-specific application data folder. Additionally, they should be created when the executable finds them missing, not by the installer.
The latter practice alone solves a multitude of problems, ranging from multiuser support ("Whaddya mean, install for everybody who uses the computer or just me? WTF?" -- your users) to the issue of requiring admin rights at installation time that are not really needed by the program itself.
Home is a bit more chaotic but most applications follow the XDG specs. Mostly. Less so with cache and state files (vscode, for example, dumps tons of cache/state files in .config instead of .cache and .local/state). And weird things like Flatpak shoving everything in .var.
I’d say things generally behave about as well as windows apps which often treat documents as a dumping ground for all kinds of files. I always have to go to pcgamingwiki to find game data locations without having to check half a dozen places.
For administration I really like the /usr and /etc divide. Vendor files go on /usr, and overrides for the running system in /etc. It’s useful to be able to peek in /usr to see defaults.You don’t really get that ability with the registry. With some more modern setups /etc is bootstrapped from /usr (for example, with systemd-tmpfiles) and you can “factory reset” a system by clearing out /etc (with some asterisks around restoring state for a few of the legacy state files still kept in /etc if the system is has manually created users/groups).
