One could make the case for something like "everybody use ini syntax", which is the Samba config file format, and the default configuration file format for Python's ConfigParser module (and most other languages have good parsers/writers including Perl). I think it has some concept of nested sections, but I'm not sure it could handle the complexity of BIND or Apache without difficulty. An Apache VirtualHost section can have many sections within, including non-unique sections (e.g. multiple Directory sections), and quite a lot of other tricky stuff, and I'm not able to think of an intuitive way to represent that in ini. I wrote an ad-injecting redirecter for Squid in the distant past that used ini format files...and I ended up having many files in a directory, because it needed nested data. My point is that there's a reason the Apache config file is as complex, and different from everything else, as it is...because it would be hard to convince simpler formats to express all of the information concisely.

Pretty much any config file format can be convinced to do just about anything, though--I'm often stunned at the whacked out crazy crap Jamie does with the Webmin configuration files, which are key=value files. He's got Perl code hiding in some of the values, for example--ternary operators and such--which gets evaluated into place as needed (this is much safer than it sounds). So, whatever format someone came up with would end up being extended as needed and that means you'd have to accomodate all of those extensions--but it still might be nicer for the folks building management tools to have at least a basic standard, even if the management tools don't necessarily know what all of the sections/directives mean.

That said, I suspect that if one could convince a standards body to get behind a "standard" config file format, you'd end up with some XML creature that no one would be happy with, not even those of us who have to parse the configuration files and would ostensibly be relieved to only have one file format for everything.

Momentum is also a problem. I don't foresee anyone on the Apache project, thinking, "Hey! Let's add a second config file parser so people can use SCFF (Standard Config File Format) so Apache configuration files will be the same as a couple of other projects!" It'd be more likely that one or two small projects would use it, and nothing much would change...we'd just have one more configuration file format to parse to support those couple of packages.

Jamie has a sort of funny, and deeply pragmatic, attitude about the whole thing: If it works, why break it? He hates it when anything changes, even to get simpler. New directives to old configuration files. Incompatible changes, even if they are simpler to parse. Etc. So, he'd probably be more angered than pleased to learn that everyone is going to change to some "universal" format.

Now that we're talking about it, I'll mention that Postfix has one of the best configuration systems I've ever seen. key=value main.cf, one-line arrays in master.cf, and space-delimited map files for all of the aliases, virtual domains, transport maps, etc. It takes a lot of files, but it's really easy to parse in just about any language, and I find it really easy to use as a human, as well. And, the kicker is that it's three file formats...so a single config file format wouldn't even work for the single Postfix service!