I'm really confused as to what exactly this is, but it looks cool. It seems to be some kind of visual programming environment, which I'm usually against on principle (BOO non-standard binary formats! ASCII text is the closest we can get to future-proof, and thus what we should be storing our source code! Down with journald! you should know the drill by now...) But interesting ideas are always interesting, so I'm willing to look into it, even if I don't like the look of it.
I don't understand your ideological point. The editable representation has no bearing whatsoever on the storage representation of a program. There is nothing preventing you from having a visual programming environment where everything is just ASCII text under the hood.
In theory it would be possible to have a visual programming language that had a readable stored representation with meaningful diff/merge/blame. But in practice I've never seen one.
DRAKON represents programs as flowcharts, and there's no reason why the underlying representation couldn't just be C, Python, or some other imperative language, and there's no reason why C or Python originally written in vi couldn't be represented in DRAKON.
I'm not a fan of flowcharts but DRAKON is of historical significance. The same would apply to GRAIL.
Other imperative visual programming languages such as Scratch could also be stored in a form resembling a textual imperative language. In other words, the visual element is largely "syntactic sugar".
Dataflow programs can also be stored as text rather than binary, but due to the nature of dataflow, this would be inconvenient to program directly in. This is because dataflow programs are graphs with only a partial order rather than ordered lists like programs in C or Lisp. This means that visual dataflow languages, such as LabVIEW and my own Full Metal Jacket (http://web.onetel.com/~hibou/fmj/FMJ.html) aren't simply syntactic sugar.
There are textual dataflow languages such as SISAL, but these require a compilation step before code is actually dataflow.
You should not be surprised to find that version control systems designed for text in which lines of code are executed sequentially by default is less useful for stored visual dataflow programs. You could still use diff/merge on the stored representation at the function level, but not easily at the line level, because the visual representation doesn't have lines of text and the order might change arbitrarily from version to version.
This is why visual dataflow programs need a visual equivalent of diff/merge, e.g. clicking on arrows to show the order in which changes were made to the graph instead of diff. Work is being done on this, e.g. Austin Henley's Yestercode (for LabVIEW), reviewed here: http://www.felienne.com/archives/5210
How does a visual programming environment prevent an ASCII text representation? Counter example: Data flow programming, or even SVG diagrams. I can't think of an exact analog, but I'd be willing to bet there is a textual VPL out there. Sure you need a tool to support conversion to a GUI, it's a different way to think!
The ResolverOne spreadsheet was a normal spreadsheet program that wrote Python code under the hood. You could then add unit tests and validate your spreadsheet calculations. The company was sold but this web version https://github.com/pythonanywhere/dirigible-spreadsheet remains and is open sourced.
I also remember a project management tool that similarly wrote Python code under the hood. And then there is the Talend Data Integration toolkit which writes and compiles Java under the hood. There is a lot of this stuff kicking around these days if you care to hunt for it.
However I think that workflow systems like Apache Taverna and jBPMN are more useful. You still write chunks of code but the framework glues it all together in a flexible manageable way instead of creating a Big Ball of Mud.
