Re: revised version
> I know the story is only 50 minutes old,
> but I've made some revisions already,
> which I think make it a little clearer
> what I'm getting at.
The window manager "Window Maker" uses a system like this; the library used is called libPropList.
It could probably be used as-is and meet most of your requirements. I'm not sure if it stores comments; all the same, it's used to excellent effect in the Window Maker configuration tool WPrefs.
That said, it was designed before XML really got accepted, so storing all the config info as xml may be a better long term solution - then at least any xml editor (or vi) would let you edit the configuration files.
Either way, the problem that remains is fitting in with existing practice. It would be nice to have an easy migration path.
If the developer has centralised all the configuration initialisation stuff, then things would be easy. You'd call the new config file reader function, which would fail if the file wasn't in the new format, and you'd call the old config file reader function.
If the developer hasn't centralised all the configuration initialisation stuff, and does it piecemeal, that's not too bad either, it just means that in each place where you probed the old config file for a setting, you'd call a new function that first checks if the config file is old or new style; if old style, it does what it used to, if new, it just grabs the named value out of the config data structure loaded in.
(I also thought that the Gnome or KDE people were tackling this problem; the idea was to have a text based config file, which got compiled into a fast-loading form. If the text file was a later date than the compiled form, the binary file was discarded and re-generated from the plain text file. But let's face it, that's simply an optimisation, it's not a requirement.)
Anyway, I agree that this is a serious and growing problem in Unix, that webmin does a great job, but that webmin's or anything elses's job would be much easier if the config file formats could be gradually moved across to all use one basic very free-format grammar, all accessible via one simple API. It would also make option setting and querying much easier for the developer.
Seriously, libproplist is well worth an examination. Ah ha! Looks like it's been incorporated into Gnome, in some sense at least. here
I think Window Maker's libproplist was designed to give the kind of functionality you had in Nextstep. They, unfortunately, stored config info only as binary files, though at least they had commands that could be used to get and set values from the command line, or even dump out the whole file in textual form. (dread and dwrite.)
That kind of thing would be very useful in this new proposal. It would be nice to be able to just query the current setting of some option, examine it, and then write back a modified form, all from the command line.