Configurations are (parts of) programs and configuration languages are also programming languages.

And code is also user interface.

So you probably don't really want a separate language for configuration, but rather a programming language that (a) has a reasonable way of creating complex object literals and (b) can be, but does not have to be, interpreted.

And you want to be able to subset and/or sandbox the language so that the power you give to those parts of the program that does the configuring is under control.

I saw this from one side when working on the BBC SportStats project, where I eliminated all the configuration files. All of them. The deployment was a single jar. That doesn't mean that there wasn't configuring going, but it was done with Java code inside the jar.

One reason for doing it this way was that deployment was just as complex/arduous for a configuration file change as it was for a code change. And the code we could easily test, abstract etc. So there were few if any benefits.

At a later stage we did have multiple instances of the app, all still using the same jar, but now delivered with different 1-2 line shell scripts that selected one of the built-in configurations.