Anybody that wants turing complete programmability in their config file is asking for pain. You can always embed such a language in a string as an escape hatch

Anybody that wants turing complete programmability in their config file is asking for pain. You can always embed such a language in a string as an escape hatch, so there's no loss of generality in any case, but it's sufficiently painful to encourage simplicity and security. But there exist computation models weaker than turing completeness that are still useful, some of those might be reasonable in a configuration file format. For example, you might want to specify a bunch of things iteratively, or perhaps with some fixed number of temporary variables; that's merely an FSM. Or even simply plain non-iterative logic with parameter passing, which is even easier to reason about and possibly still useful; i.e. re-usable templates without iteration or recursion. I can at least imagine such a configuration file format could be both simple enough for human and machine to reason about, and flexible enough to add value over (say) json. But the devil is in the details; and it's not always immediately obvious what's too complex. In any case, json5 looks like what json should have been from day 1; several of the really critical improvements were common JS practice when json was invented. I'm a little worried about the IdentifierName extension, since that's more than what javascript itself allows (no reserved keywords!). But json5 is also an interoperability problem. The nice thing about a (good) standard is the that if it works someplace, it'll work anywhere. Add json5 into the mix, and that's not the case anymore. Then again, there aren't a huge number of plausible successors to json, so maybe this is the best we can hope for. And it's trivial to down-convert to plain json, which means it's not too bad, I guess? I wish json5 simply worked everywhere ;-).