But regardless, would you think anything new will become mainstream in this space? We already have json, yaml, perhaps a few more. It appears that the problem that the new ones solve start paying off when the software they configure go over some pretty high complexity threshold.
With Cue, I personally think it is uglier than TOML and Dhall and only slightly less reader-ambiguous than YAML. But it’s like game theory: you have these strategies you add in the middle which come with half the costs and half the benefits and so they aren't strongly dominated by any of the other options and they get their fair share of the Nash equilibrium because they occupy that middle ground. So if one cannot say “this is clearly a wrong choice” one can nevertheless default to “this is a possible choice but I just have a lot of options and I can choose to be more arbitrary about what's important to me.
At one point in the early 00s I needed a shared hosting provider for a small site, and all of them looked unbelievably the same. I adopted the first narrowing criterion of “Reject any hosting provider which has a name of two words mashed together in PascalCase”, which IIRC cleared away well over half of the competition. There's nothing wrong with them, I just had a lot of options so I could afford to say “this looks so ugly and repetitive to me and I don't want to do it.”
That cleared away a lot but not enough to narrow it down to a few options, so I then arbitrarily limited it again, “no free hosting providers whose Contact Us links contain stock photography of a solitary white woman wearing a headset.” (Like she can be in a group, she can be a minority race, she can be holding a phone, she can be an actual employee of the given company, it could be somewhere else where it is not a link you click on, like a splash page—any of those is fine, just stop trying to suggest “we are trendy and support diversity but not so much diversity that you worry your precious white man head about being routed to a call center.”) That one was actually unreasonably effective and got it down another 80-90% or so to a manageable handful.
When you have a lot of middling options that cannot strictly be eliminated for technical merit the soft things are valuable for winnowing.
I think you're missing the main point of these languages.
YAML, TOML, JSON are all basically the same thing modulo syntactic differences, which are largely a matter of taste.
Dhall, Cue, Jsonnet, BCL, etc. are in a different league - they allow you to express some computations with data in your config. It helps you to eliminate boilerplate and duplication in your config, avoid copy-paste mistakes, make configs more concise, express some complex abstractions specific to your domain. They're miniature programming languages for your configuration data.
If all you have is a few dozen key/value pairs to specify, it doesn't really matter which you choose, just a matter of taste. But as your config files suddenly span thousands LoC, duplicate same things over and over, need to configure dozens of different things (e.g. with jsonnet out of a single jsonnet source you can generate multiple configs for basically anything json/yaml/ini driven), get edited by multiple teams and you start looking for better ways to structure this mess, that's when these more advanced config languages come in to rescue your sanity.
It's nice to have type safety, but the way it's implemented in Cue is unintuitive and too complex to be practical.
The approach of JSON (borrowed from XML) to have a separate schema file is better and you can use to to just validate.
