Ask HN: Friendly Debate over Application Configuration

My perspective is clouded by my line of work (enterprise applications) but a lot of the applications I work with are HEAVILY configuration driven. When they were originally built the standard practice was the app.config. There are 2-3 competitors in this field and I have worked with all of them. These apps cross multiple business domains from the front to the back office. That means that there are literally hundreds of configs for everything from data connections to report definitions to key connections between tables/entities. That ends up being a nightmare to maintain when doing customization and implementation or migrations. Afterwards, it ends up being reasonably static and will "just work".

I still think its clunky, and am curious what other folks do for highly configurable applications that require a lot of configuration. I think that aside from the bare necessities to stand up an environment, a database is a great way to store and maintain configuration. I dont think its without flaws or drawbacks, but the number of times I have to debug "the given key is already in the dictionary" error messages (which by default the .NET framework wont even tell you what key that is) when a database could immediately spit out that an insert failed due to constraint failures with the values is so much more convenient. What are some better practices to configure apps?