Sure, but it is a configuration format if it is intended to be used in all kind of languages you have to show bow to deal with it in all kind of languages.

Checks that might be trivial in OCaml might be utter footguns in say C.

Don't get me wrong here, I get that this is someones spare time project that they might use for themselves only. I am fine with that. But I am unconvinced if the (I admit: well demonstrated) simplicity of the format translates to simplicity of use in the scope it aimed for (replacement for other wide spread configuration formats).

I don't say it is impossible (or even unlikely) that this is an improvement, I just caution against seeing an elegant minimalist approach and automatically assuming it makes things simpler — remember, computers with their binary file systems already have the most simple format that could exist: zero or one. Yet somehow people shot themselves in the foot parsing those for decades. Much of the complexity of computer systems stems from managing the simplicity of the underlying components (if we ignore the thick layer historically grown cruft).

What would it take to change my mind? Elegant examples how to parse all the examples in that post using major programming languages (C, C++, Javascript, Java, Python, Go, Rust, ...). That is ofc a lot of work, but if the format should be adopted that work would be needed anyways.

Part of the power of the idea is how amenable this is to property-based testing.

And it really only takes one solid implementation that can be wrapped/called from other languages to do well. (Or perhaps one per an ecosystem like JVM, .NET, WASM, anything that can be relatively easily called from C, anywhere Python is used for scripting, etc.)

And because of the formalisms involved, you could have a pretty precise and complete spec defined.