Just going through the section for why they think it beats YAML:
> YAML can be ambiguous about what types the data written into it is.
If you're worried about data types, that sounds like a job for a proper data storage format rather than putting it into a configuration file, no?
> There's also a persistent issue where very large YAML files become unmanageable, especially due to the significant indentation feature.
That sounds like a poorly designed configuration setup. If you've got a nested config that complex, by my reckoning, it should be reorganized into flatter data structures or broken down into more specific configuration files regardless of what the format is.
>YAML is a great, widespread language. Unlike KDL, which is node-based (like XML or HTML), it's based on map and array data structures, which can provide an easier serialization experience in some cases.
Saying that processing node-based formats is more difficult in 'some cases' is a particularly charitable take, especially when they're touting their ability to handle very large, complex configurations.
> KDL is designed to avoid these particular pitfalls by always being explicit about types, and having clearly-delimited scope (and the ability to auto-indent/auto-format). Syntax errors are easier to catch, and large files are (hopefully!) much more manageable.
It seems like it adds significant complexity over YAML to mitigate abuse of YAML... but wouldn't it just be better to do a better job using YAML?
I do tend to be biased towards conforming to the usage practices of existing tools rather than adopting new tools for edge cases or minor conflicts because learning new tools tends to have a slightly higher cognitive toll for me than some others— but as a general rule, I don't see a problem with only switching tools because you have a problem that's significantly more difficult or less efficient to solve with the old tool.
Maybe there's some really clear use cases that aren't obvious to me for whatever reason.