I can see where they are going with things like Metadesk, but it's ultimately just another file format (text or otherwise) to represent rich structured data.
The endgoal is probably to allow neater refactoring opportunities and raise the level of efficiency by standardising on an easier-to-parse-into-AST-like-structure syntax, enabling generic tools to be built that will deal with such structures directly.
While I sense that there is something smart that could be done in that area, there are already plenty of de facto standardized languages for structured data (most notably XML), and already a bunch of real world programming languages that work.
So I think it'd be easier to grasp their goals if they started off of an existing language ecosystem (that language spec is the definition for their AST parser), and attempted to build the tools they want: this would have more quickly formalized what's missing in the source code format for it to remain human editable, but at the same time easier and richer to parse.
Again, it's all a bit vague since you can build a development environment based on text files where you are not seeing all of that generated text at all times (if ever).
As the goal seems to be to find improvements to the process of program development while being unconstrained by complexity of (re)parsing text files repeatedly, I would have started with trying to add those improvements and ignoring the slowness/cost of parsing (or simply used an existing language that's cheap to parse, like Lisp).
I agree, it seems like an editor based on direct AST manipulation could work pretty well with existing languages (I actually prototyped one a long time ago in university). Some languages like C with text-based preprocessors might cause some headaches but there are others that probably wouldn't be too bad.
There's pretty far you can go with text-based formats since you aren't obligated to display the file exactly as it's stored on disk (and many current IDEs do minor code folding things). For example embedded images can be displayed inline in the source code, but be stored as some loadImage() function on disk. You could even have some comments with base64 binary data if you really needed - at that point binary vs text is mostly a performance issue, but parsing is usually pretty fast so being text-based might still have an advantage because of better interoperability with source control etc.
The endgoal is probably to allow neater refactoring opportunities and raise the level of efficiency by standardising on an easier-to-parse-into-AST-like-structure syntax, enabling generic tools to be built that will deal with such structures directly.
While I sense that there is something smart that could be done in that area, there are already plenty of de facto standardized languages for structured data (most notably XML), and already a bunch of real world programming languages that work.
So I think it'd be easier to grasp their goals if they started off of an existing language ecosystem (that language spec is the definition for their AST parser), and attempted to build the tools they want: this would have more quickly formalized what's missing in the source code format for it to remain human editable, but at the same time easier and richer to parse.
Again, it's all a bit vague since you can build a development environment based on text files where you are not seeing all of that generated text at all times (if ever).
As the goal seems to be to find improvements to the process of program development while being unconstrained by complexity of (re)parsing text files repeatedly, I would have started with trying to add those improvements and ignoring the slowness/cost of parsing (or simply used an existing language that's cheap to parse, like Lisp).