The world desperately needs a replacement for YAML.
TOML is fine for configuration, but not an adequate solution for representing arbitrary data.
JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc.
Jsonnet (a derivative of Google's internal configuration language) is very good, but has failed to reach widespread adoption.
Cue is a newer Jsonnet-inspired language that ticks a lot of boxes for me (strict, schema support, human-readable, compact), but has not seen wide adoption.
Protobuf has a JSON-like text format that's friendlier, but I don't think it's widely adopted, and as I recall, it inherits a lot of Protobufisms.
Dhall is interesting, but a bit too complex to replace YAML.
Starlark is a neat language, but has the same problem as Dhall. It's essentially a stripped-down Python.
Amazon Ion [1] is neat, but I've not seen any adoption outside of AWS.
NestedText [2] looks promising, but it's just a Python library.
StrictYAML [3] is a nice attempt at cleaning up YAML. But we need a new language with wide adoption across many popular languages, and this is Python only.
Any others?
S-expressions are super easy to parse and are fairly easy for humans to read. See e.g. using s-expressions in OCaml: https://dev.realworldocaml.org/data-serialization.html
S-expressions inherits all trouble with data types from json (dates, times, booleans, integer size, number vs numeric string).
You get neat ways of nesting data, but that is not enough for a robust and mistake-resilient configuration language.
The problem isn't parsing in itself. The problem is having clear sematics, without devolving into full SGML DTDs (or worse still, XML schemas).
Hm, not sure that's true, S-expressions would only define the "shape" of how you're defining something, not the semantics of how you're defining something. EDN https://github.com/edn-format/edn for all purposes is S-expressions and have support for custom literals and more, to avoid "the trouble with data types from JSON"