I wanted to expand on this thought. I already stated I think standardizing and consolidating integration configuration with a common store, API, and interface is important for a proper, modern OS. Not to mention, as I previously noted, having a consistent configuration store / API / interface gives users of all levels the ability to go in and change both system and application settings in one place.
The reason why there is a registry for Windows is because there are so many apps that actually integrate with the operating system–having a consistent uninstall path for end users (Add/Remove Programs control panel), adding file type icons and MIME types (yes, Be/Haiku has its own API for this), having the ability to load up an OS-registered COM server by CLSID (a GUID) or by name (Haiku doesn’t support COM so this is moot), having shell extensions so that you can do things like right-click an icon and special context menu options show up, etc. But I agree that putting EVERYTHING in the Registry as Microsoft makes a habit of doing is just stupid, particularly if it is spaghetti where dependency settings are left unmapped and undocumented.
Secondly, I am as disgusted as everyone else with the mess that the Windows Registry has become. But I really don’t think that the problem is the presence of the registry itself. I think the problem is inadequate standards and crappy structure design. For example, if an installed app MUST put its installation log into the registry, it should be forked in an “Installations” branch that someone doing a manual uninstall should be able to just right-click “Installations/MyApp” and choose “Delete”, and then all of the setup-related information is removed. Shared libraries should be the same, and not accessed solely through a GUID (I HATE trying to find GUID-ified registry keys!!). Figuring out how to completely manually uninstall a corrupted Windows component installation takes me a couple hours of searching values that contain the old file path, and then I have to delete one randomly generated GUID named registry branch after another, at least a hundred times, before Windows itself will acknowledge that the thing isn’t installed.
So in other words, the suggestion of a registry also infers a suggestion of a halfway decent structure / design, unlike the mess that the Windows registry is. Get the structures cleanly designed and standardize on it, and then most of the arguments against the registry become moot.
As for the arguments about having one big, bloated file managing configurations, that will break the OS if the one file gets corrupted, I would argue that that’s what makes it reliable. Build the store accessor on SQLLite or something, do transactional logging, and make regular backups. It’s much more of a pain in the neck to restore broken RPM history chains, and config files inside individual app directories don’t befit OS integration requirements, nor, for that matter, consistency in the real user experience.
On the other hand, if the OP (original post) was more along the lines of inter-process communication, using the registry for that is abuse. That’s not what a registry is for. The registry is just a database for the local computer for persisting configuration data, not for memory swappage from one app to another.