Thinking about it, I'm not sure any interchange spec would leave useful room for innovation. This isn't like EPS or PDF or something where the kind of output is well-defined (printable graphics + text) and the innovation is in the editing interface. The innovation in canvas apps is surely in the semantics of the nodes themselves; but if you add some new node type with special behavior, how can you usefully export that to other apps? You could make it a black box that can round-trip safely, but that doesn't seem very useful. Maybe if it's something like an HTML embed or iframe?
It would be fun to go the postscript route and have the nodes be specified by some bytecode on some VM that lays the objects out on the canvas while specifying their editable properties.
Then, conforming implementations could render any document just by following the instructions, while editors that actually understand them can provide their own high-level control.
The trick is keeping it editable, which postscript doesn’t do well.
Example: if the language is strong enough to, say, implement force-directed node layout, an editor that doesn’t understand it could still add nodes and they would move around according to the document author’s wishes whereas perhaps the original editor might have more powerful editing capabilities.
My very first thought about this format was that someone is definitely going to pervert it to be used as a graphics format, and for that it's woefully inadequate. I decided to hold my tongue since it's not the creators' fault that someone will misuse it, but I can totally see people adding optional ad hoc fields to nodes to allow for example all sorts of fancy line styles.
I like to think of it like the unist ecosystem for ASTs. Unist provides a baseline spec that compatible tools can use to comb an AST. Then, specific AST tools like hast for HTML or sast for CSS/SCSS can add their own metadata on top.
I'm imagining an ecosystem of "adapters" that would help you translate some of the metadata across providers.
