Conversely, I've been using quite a bit of Jsonnet in different projects for a few years now, and it's a life changer.
Here's a public example - using Jsonnet to parametrize all core resources of a bare metal Kubernetes cluster: [1]. This in turn uses cluster.libsonnet [2], which sets up Calico, Metallb, Rook, Nginx-Ingress-Controller, Cert-Manager, CoreDNS, ...
Note that this top-level file aims to be the _entire_ source of truth for that particular cluster. I know of people who are reusing some of the dependent lib/*libsonnet code in their own deployments, which shows that this is not just abstraction for the sake of abstraction.
Jsonnet isn't perfect, but it allows for actual building of abstraction layers in configuration, guaranteed pure evaluation, and not a single line of text templated or repeated YAML.
Does a "configuration language" specifically incorporate features for "overlaid" or "unified from parts" configuration?
Much like layered dockerfiles, mature configuration often comes from several places: env vars, configuration appropriate for checkin to git (no secrets), secrets configuration, and of course the old environment-specific configuration.
All of that merges to "The Configuration".
Also, these seem close to templating languages.
I've done this several times with a "stacked map" implementation (much like the JSP key lookups went through page / session / application scopes, or even more convoluted for Spring Webflow.
Answer for Jsonnet: layering/overrides from multiple sources: yes, as you define it (it's a programming language, the logic is yours to define, based on your particular usecase). But no access from environment variables, as that's inpure, and not really in scope for them.
Here's a public example - using Jsonnet to parametrize all core resources of a bare metal Kubernetes cluster: [1]. This in turn uses cluster.libsonnet [2], which sets up Calico, Metallb, Rook, Nginx-Ingress-Controller, Cert-Manager, CoreDNS, ...
Note that this top-level file aims to be the _entire_ source of truth for that particular cluster. I know of people who are reusing some of the dependent lib/*libsonnet code in their own deployments, which shows that this is not just abstraction for the sake of abstraction.
Jsonnet isn't perfect, but it allows for actual building of abstraction layers in configuration, guaranteed pure evaluation, and not a single line of text templated or repeated YAML.
[1] - https://cs.hackerspace.pl/hscloud/-/blob/cluster/kube/k0.lib...
[2] - https://cs.hackerspace.pl/hscloud/-/blob/cluster/kube/cluste...