Merely for your consideration, I suspect a lot of people have opposition to XML because it is noisy when edited by a human:

    <httpd>
      <baseDir>/opt/server</baseDir>
    </httpd>

Of that snippet, "</baseDir>" and "</httpd>" are characters of my life that I will never get back, since they're just parser niceities and not _value_

Moving up the enlightenment chain:

    {"httpd": {"baseDir": "/opt/server"}}

or its brace-and-quoteless friend:

    httpd:
       baseDir: /opt/server

place a lot more emphasis on the payload and less on the packaging

It is a matter of preference and legibility.

With XML and other "fully qualified" syntaxes the named closing tag makes it easy to visually see where a block starts and stops. Humans parse the text too. This begs the question: Do you read config more or do you write config more?

Braces and parens all look the same, so its harder to visually match them. "But wait," you may say, "my editor / IDE does brace and paren matching so I can easily see and jump to the corresponding brace or paren." True, but doesn't your editor / IDE also support or have plugins for automatic HTML / XML end tag insertion?

Personally, I am equally comfortable with XML and JSON style configuration, but I find the brace-and-quoteless style unsettling because I believe that whitespace is a poor choice for delimiting structure. Your opinion may vary and that is fine. Do what works best for you.

But you can do

     <httpd baseDir="/opt/server"/>

and it is shorter than the JSON.

In my opinion one of the weaknesses of XML is that it gives so many ways to express the same data, in attributes, as nested elements, with CDATA, and probably different other ways. And often it is a matter of taste. So in the end you come up with so many approaches to express similar structures.

>> So in the end you come up with so many approaches to express similar structures.

Expressiveness and flexibility are good so that you can define configuration to meet the needs of the system or application you are building.

XML Schema, Relax NG, etc. can be used to specify how the XML configuration should be structured, limits on data types, required versus optional configuration items.

As I said before, XML gets a lot of flack for being verbose, ugly, and complicated, but it is mature, widely-supported, and might be worth considering depending on your needs.

Some parts are extremly ugly, and mostly pointless. namespaces, doctype, processing instructions.

This is well-formed xml and good way to confuse people:

     <?xml version="1.0"?><!DOCTYPE abc[<?abc >]]<abc><abc/>]>>?>]><?x?><a/><?x <(x)>>?>

The main reason I'm not using XML seriously is that it only really has a single native, scalar type: string. Sure, you can schema validate away a large part of this problem, but it's still somewhat of a wart.

> Again, XSLT could be used, but should your configuration really need to be Turing-complete?

A few of OPs suggestions are not Turing complete, but rather total programming languages as is the case with Dhall.

> You can technically put logic in XML using XSLT (https://www.w3.org/TR/2017/REC-xslt-30-20170608/), but I would ask if one SHOULD put logic into your configuration.

Well, definitely not XSLT.