This is a really good question and to be well covered it needs a really deep answer. I will write a short draft here due to lack of the time, but will be happy to talk more about it after the release. Maybe a blog post would be suitable here, just an idea worth considering by our team :)

If you are thinking about visual language you have to think about many constructions that collectively give you user experience, including available basic construction blocks (how looping, branching works etc), structures, lambdas, every language construction, how you give hints to user what is possible and what is wrong and additionally how to do this real 2 way transformation of code and graph.

Luna infers types and displays colors according to them. We use algebraic data types, lazy evaluation, pattern matching and purely functional paradigm which suits graph visualization really well. We fine tune performance by allowing lazy data visualisation and many, many more things. I don't know how we can even visualize standard OO abstractions to be usable and pleasant to work in the visual form. It does NOT mean we did not think about it. We did for a long time.

Sure you can utilize Luna gui to visualize anything, including python code, but it would be insanely hard to deliver similar functionalities to what Luna offers out of the box (which is available by careful design of both representations).

I feel thin answer is very vague, but I hope I put a little light on how complex this task is. Did I answered your question (at last partially)?

Yes, thanks, I think you did, what you can ;)

I would like to try out the beta once you publish(soon?), to see more what you do and understand better (and see whether my ideas could be compatible, or not)

Another thing I've been thinking about in the past is how do you preserve formatting when translating between visual/textual. Eg, if I place a visual node and then edit the text, does it preserve my visual layout? This is important because I've used Max/MSP in the past and I would logically lay out the code by function to make it easier to comprehend. Similarly, preserving whitespace in the textual form even when editing the visual form.

I don't know if or how luna handles this, but its a concern that I've had trouble with when I was thinking about something similar in the past.

It does preserve. We keep some special markers in the text files and we track the position of the markers. The markers have associated metadata kept on the end of source file. Neither markers, nor metadata is seen during the graph editing, so it works transparently for the end user.

Awesome! That's great to hear.