> The very first example is a document with metadata like title, author, etc. It's called a "document language".

Static sites generators often have content in markdown, but I also saw quite some use of YAML or JSON.

  > It seems to be straddling documents and configuration, which in my experience makes for a lot of awkwardness.

It seems to be for structured data, that can be both a document of some sorts or a configuration; just like YAML/JSON/XML is used for both.

  > There are two specifications for writing KDL that can be losslessly translated between it and JSON or XML.
  > These specifications define a stricter subset of KDL that, even if NOT entirely idiomatic, is still valid and fits into the data models of the other two languages: (emphasis mine)

Note that the author means two separate, additional specifications about how to losslessly translate (iow. convert) between KDL and JSON or XML, not that the actual KDL spec has provisions for reading JSON/XML as KDL. I mean, FWICT some JSON file may parse though, but it's not like YAML, which is an actual superset of JSON; now _that_ adds awkwardness.

One can also create a spec to transform JSON into XML, that does not mean it has anything directly to do with the XML spec.

I rather see this as effort to make it easier to switch to KDL, if one finds its characteristics nice(r).