Actually that is exactly what I want which is why I signed up for the Luna beta months ago. We have had flow based programming for a while in the synth and robotics communities and nesting diagrams within each other is the normal thing. For many tasks you can produce elaborate working interactive UIs without ever writing code. My favorite software allowed adding code in C and assembler, though then they shifted focus towards the robotics control market and reoriented it around Ruby.
There are two big advantages in working primarily at the graphic level: you can trace control flows visually and you don't have to know all the libraries and syntax. Instead you can select from a palette and find out what they do by using them, and it should be the computer's job to worry about syntax anyway.
However, I do not agree with your point that people don't want to code with mouse. Actually, connecting high level components visually, tweaking their parameters (with sliders, color choosers and other widgets) and observing how it affects the result you got is MUCH faster than writing code. There is of course some "base level". If you code something low-level it is much better to use code then. Where this "base level" is, depends on you and your preferences.
I would love to hear more from you after you try Luna and try to create something more complex in it! :)
I previously looked at stuff like https://flowhub.io/ide/ which is a dataflow language spec and editor. Specifically the js version https://noflojs.org/example/ for compiling graphs into js for some canvas image pipeline work.
Each component has an underlying text representation that you can edit like you guys. But that representation isn't code. It's just the configuration of the node.
This isn't what I want! I want to architect the dataflow on a whiteboard, code it normally (a new language is okay), and then have it visualize the same dataflow for debugging (with help grouping/organizing if needed). Every programmer already does this in their head but without the visual aid.
(Focusing too much on the graphical representation is a mistake. There's only a handful of granularities that are worth whiteboard diagramming and people definitely don't want to code with a mouse dragging and zooming. But having the diagram at specific architectural level when you do need it is invaluable)
I haven't tried your product out yet so I don't know if you guys got it right, but at the very least you guys recognize the importance of "dual syntax representation" as a selling point!