Is this better merged into T298633 as a general graphical-programming-language support task?

I'd like to be involved in this investigation.

See, for example:

• https://en.wikipedia.org/wiki/File:Wikimania_2019_-_Multilingual_JavaScript.pdf
• https://en.wikipedia.org/w/index.php?title=File:Wikimania_2019_-_Let%27s_Completely_Change_How_Templates_Work!.pdf&page=30
• https://en.wikipedia.org/w/index.php?title=File:Wikimania_2019_-_Let%27s_Completely_Change_How_Templates_Work!.pdf&page=31
• https://github.com/cscott/turtlescript

Scratch and eToys are good models to use, FWIW, but I've got a personal lean toward things with 1:1 mappings w/ (a subset of) JavaScript (like the turtlescript example above). Note that I'd almost certainly use Blockly as the UX layer for turtlescript if I were building it in 2021, instead of hand-rolling my own UX.

(a perhaps non-obvious anecdote is that localization is/was a big issue w/ block-based representations. some languages have wildly varying string lengths to describe certain programming concepts, and some of these stretch the graphical layout of a 'block'. eToys and Scratch made it work, but the localization effort was more involved than "merely" translation.)

I wrote an experimental script to convert blocks from the Visual Programming languages Snap! and Scratch into source code based on a Mapping in a CSV-File. You can find the source code here. It is experimental and I am interested and try to extend the functionality of it. For example adding support for nested functions and also a reverse block create script. So you have source code as Input and get Blocks in a visual programming language as output.

I've made a prototype for how compositions could be represented and edited as blocks, using Blockly.
It doesn't pull any live data from Wikifunctions, but I've tried to have it export in the canonical JSON form, and maybe it can find a use just because of that. Blockly can accommodate simple type checks, so I think with a bit of effort I could make that work for the few included types—but the feeling I've gotten from trying to pull in plugin libraries is that there is only the illusion of plugin libraries, and further UI/UX improvements will likely require copy+pasting whole chunks of code and hammering them into shape. Which mirrors what @Feeglgeef told me on IRC.
All that said, I hope this prototype can at least convince more people that a block interface is a good idea, even if Blockly itself isn't used for the final product.

Finally found the motivation to clean up my local changes to the Blockly prototype and push. (In the meantime, Google has transferred ownership of the library to Raspberry Pi.)
The main technical changes since April are the inclusion of the type checks I alluded to, and fixes to broken or incorrect serialisation. I also populated the toolbox with many list, bool, and number functions and wrote some usage instructions.
I wouldn't say that makes it usable as an alternative editor or even a sandbox for compositions, but it does now look a lot more like what I'd envisioned. Here's a comparison of how a bunch of nested list operations is visualised in Blockly vs. the live Wikifunctions:

One thing I'd like to emphasise is how much of a productivity boost drag-and-drop refactoring would be. The edit interface for compositions has really been getting on my nerves recently, to the point where I would use this janky prototype as my primary editor if only it could import/export to the live wiki.
edit: Nevermind, I got nerd sniped and added "exporting" in the form of the new ?call= links. That was enough for me to do real work, so this is probably going to be my primary editor now. Yay?