Few observations from playing around with the demo:
* you claim that code editing is totally structured, but at the same time it is possible to delete one of the two parentheses thus creating broken expression, and no straight forward way to add the missing parenthesis since writing of them happens only in pairs. It feels like with exception to top level statements.
* when editing it's easy to end up with stray empty tokens which result in confusing syntax errors (that's even worse than significant whitespaces in plaintext editing)
Overall it fells like this feels like worse parts of both sides: syntax errors of traditional plaintext code editing, and constrained editing ability of structured code editing.
> For professional programmers, the editor is probably pretty frustrating to use (no vim keybindings!)
It is not the lack of vim keybindings that's causing frustration, it's the lack of almost any keyboard input or ability to type in if you know what you are trying to enter and being forced to search for operators within tiny scrollable 3x3 grid. Either the editing should be a lot more constrained with clearly displayed placeholder slots like it is in scratch, or the editor should allow typing in expressions using keyboard.
Consider that the goal of project is helping transitioning from block editing to more practically used programming languages -> I would suggest exploring the second approach. Keep the current menu input method, but when a user presses a key insert or start editing appropriate type token. That is if the expression insertion menu is open and user presses a number key just start editing a number, they would have to use keyboard for entering it anyway if they clicked on number input button in the dropdown. Similar if you press + key, and + is token that's currently available in the insertion dropdown just insert '+'.
Other pain point was editing. At statement level I would say it's reasonable, but expression level any editing felt miserable. In some cases it felt like simplest way of editing is erasing everything, in other moments it felt like some kind of bad Levenshtein distance code golfing. Lets say you have expression `a+b` and you later decide to change it to `(a+b)*c`. Your options are either erase everything and rewrite from scratch or insert '()' before a+b, insert '()' after a+b, erase ) from first parentheses pair, erase ( from second parentheses pair, add * and c. Neither plaintext editing nor good block based code editing have this problem. Also you can't select and copy or move anything except whole statements.
Overall with exception of top level statements, it hardly enforces any structure of code and you can enter almost arbitrary sequence of expression tokens forming an invalid expression.That kind of defeats the point of having somewhat structured non typing based input.
Bug: In chromium the insertion dropdown shows 3x3 grid, but scrolling with mousewheel scrolls by 4 lines. Meaning you can't easily select anything from 4th row like '*'. Can't you just show all the operators? Even on mobile phone there should be enough space to show 3x9 or 5x5 grid.
Bug2: drag and dropping an if statement inside itself caused the page to hangup. Infinite loop? While dragging a statement with nested statements like if or while should highlight the whole block not just the first line.