Doesn't that describe disk filesystems too? And Unix file namespace in particular (a single hierarchy unifying several block devices, just like registry is composed of several on-disk files)? What about all that junk in one's $HOME?
Over on one end you have papersize, a file containing a single word with seemingly no relation to any installed software. In httpd.conf we have a sort of SGML that’s mostly line oriented CDATA. aliases and many other mail files are all members of the Berkeley DB lineage of key value stores. default/ feels like it’s also a key value store but one suspects that one could probably put a command in there and something would execute it. rc.d is 99% code but with semantics in the symlinks too (see also Debian’s alternatives.) A very large number of files look like braced C code; named.conf even requires terminal semicolons!
There’s no value in either consistency or diversity of the underlying implementation be it a registry — the registry, or a gconf thing — or a filesystem smorgasbord of config languages. Without the discipline (authoritarianism?) of a social structure — for example a “company” with a hierarchical leadership that can promote/fire you — you will get diversity in any system.
I just reminded myself of the time I used ansible YAML Jinja templates to control EdgeRouter config files that programmatically built config in /etc. Time for a leisurely stroll in a real garden I think, far away from a computer.
Windows programs proliferate $HOME junk, too. And that's an issue in its own right, which should be addressed by platform-specific application dirs (e.g. the platformdirs library for python).
That doesn't prevent it from becoming a KV dumping ground for every process and their dog to litter with whatever, at all. Not in the least because it's already that, which a cursory look through /tmp and /var supports.
> There's nothing with less bottleneck to the filesystem besides raw device access
I thought there was considerable effort from the Linux kernel team spend on parallelization of the inode and buffers management but if you say that the main bottleneck is the raw device speed then sure, I'll believe you. It's not like NVMe protocl has design with 64K command queues each 64K command long because the OS simply can't saturate the device's bandwith otherwise, right?