A sibling comment already mentions Pulumi. There is also mgmt, which is a statically-typed, functional, and reactive configuration language. In mgmt the configuration is a function of the system's state. Configuration is automatically recomputed and reapplied when the relevant state changes. This is something I have on many occasions wanted in a configuration management tool. For an introduction to how it works you can read https://purpleidea.com/blog/2018/02/05/mgmt-configuration-la.... Mgmt is not yet production-ready.

I expect the trend of YAML configuration with templating hacks on top (which comes in at least two varieties: templates producing YAML as text like in Salt and templates inside YAML leaf nodes like in Ansible) to be seen as the early 2010s equivalent of growing an ad hoc programming language on top of XML. It tends to happen, since complex configuration needs to reuse values and contain expressions and it is easy to implement in a backwards-compatible way. The users will appreciate it if they had nothing before, but it locks them into a path of writing code (because it is code) with an ugly error-prone syntax, complex two-layered semantics, and little abstraction. I have got good mileage out of Ansible, but I would enjoy using it a lot more if the playbooks were written in a restricted subset of Python, for example.

You can do better without types, too. Writing Scheme, Lua, Tcl, etc. code as configuration even predates the XML craze. (Tcl and Lua code can be sandboxed and limited in the number interpreter instructions and wall-clock run time. Tcl in particular has extensive sandboxing capabilities built in with "safe interpreters".). The appearance of restricted configuration languages like Starlark (https://github.com/google/starlark-go), Jsonnet (https://jsonnet.org/), and Dhall (https://dhall-lang.org/) looks like a reaction to the trend of JSON/YAML templating, and it is a welcome reaction.