That's an odd statement. Can you please explain why you believe that JSON is "unnecessarily complicated" to represent metadata.

* JSON is just barely powerful enough to need a library to parse it, but not powerful enough to have comments or trailing commas, so editing is needlessly annoying.

* It's human-readable, but deciphering nested data structures is annoying, especially when things are formatted as long lines. If you have to pipe something to jq to be able to read it, it's broken as a text-based document format.

* JSON is needlessly strict. If I write {foo: 5}, my intent is crystal clear. I shouldn't have to write {"foo": 5}. Come on. Who's really helped by this kind of syntactic hairshirt?

* despite being a strict schoolmarm of text formats, JSON is still vague. Yes, it has numbers. How big can they be? Who knows?

I mean, JSON is fine-ish, I guess, as an interchange format, in which I'm looking at it only for the occasional debugging session. But as a format for documents meant to be read by humans? Ugh. Anything, anything at all but JSON.

When editing a patch file, how often do you edit metadata beyond the file content differences?

It seems that the proposed DiffX is meant to be produced/edited only by machines, so JSON doesn't seem too much of a problem for this use case.

Diffx authors wrote a prototype in Python where JSON support is built-in. Go parse it in bash or C.

Having to parse JSON for the sake of applying a patch is not exactly wise

Luckily, this does not matter in DiffX because the whole thing goes up in flames when you change the length anyways :)