Making an app work in the config framework is the app developers problem.
Many of these comments seem to revolve around the difficulty of making the config framework fit k's of different file formats or what happens when the formats change between versions, etc. The developer of the application needs to give their app the ability to be managed by the framework. So, Apache says, "Our config can be managed by your-config-app." You open your-config-app and point to Apache's config file, which is self-defining, and the hierarchy of Apache options opens in your-config-app. No need for standard config file locations and the "leakage" is the responsibility of the developer.
Just one thing to which I can't help but respond specifically: The specifications of this project explicitly called for the retainment of native config file formats. None of the beauty of *nix's configurability is lost; it's simply exposed.