Yeah, I'm withholding judgement on Luna specifically, until we can see it in action. Their model could be a good one, it all depends on whether they treat the text representation as a first class citizen or not.
1) Standard AST - one that is a common and extendible syntax representation. Both the textual code as well as visual graphs are able to translate to and from this AST model. To be most precise - both representations are just some kind plug-ins (with some funny type-level-safety built-in) over this AST representation, so they are both first class citizens and they are completely equal to each other.
2) Core AST - a desugared, type-checked, minimal lambda calculus language, that is used to perform all sort of optimizations before next steps towards generating the target code (assembly / js).
We treat the graphical interface exactly the same way, never favoriting any representation over the other. If you would like to develop another one, like natural language input, you have just to provide methods for translating it to and from AST and our infrastructure delivers everything you need to translate it to and from visual or textual one.
I hope this spots a light over the internal design of Luna :)