> what _is_ the array? Is it a patch? A canvas? A file? When you use a dictionary, the name of the key is helpful in clearing this up.

Well ... this just cosmetics ... I think the array is very flexible, in that you can just stuff objects in there. And, there will be arrays anyways. What you suggested is actually not possible :

{ "elements" : { "obj" : {"id" : 0, "type": "osc~", "args": [440]}, "obj" : {"id" : 1, "type": "dac~"}, "connect" : {"from": [0, 0], "to": [1, 0]}, "connect" : {"from": [0, 0], "to": [1, 1]}
}
}

In a map, keys need to be unique. So, you would need to write :

{ "elements" : { "obj" : [
{"id" : 0, "type": "osc~", "args": [440]}, {"id" : 1, "type": "dac~"},
],
 "connect" : [
{"from": [0, 0], "to": [1, 0]}, {"from": [0, 0], "to": [1, 1]}
]
}
}

Which imo, is not much better than :

[
{"class": "object", "id" : 0, "type": "osc~", "args": [440]},
{"class": "object", "id" : 1, "type": "dac~"},
{"class": "connect", "from": [0, 0], "to": [1, 0]},
{"class": "canvas", ...},  ]

in that there is less nesting, it is thus a bit simpler... but I guess that's a detail.

> It can also simplify parsing order

That's true ...

> I think [GUI info] deserves a classification higher than 'extra info'. A formal extension of the format, so to speak, since the majority of use cases involving a pd patch will require a visual layout.

That's a very good point, ... it's a good idea to specify GUI infos, for better interoperability, but it should be explicitly said that this is optional information, and parsers must handle the case when those are missing.

@Jonathan : Yes, backward compatibility is mandatory, in that the new format must be a subset of the old format - I mean, "semantical" subset : it must be able to contain all the infos contained in old file format
And we suggested to write a converter to help this.