For visual low-code programming to align with how I visualize code, it would need to have one modality for when I'm writing, and a much richer, more complex modality for when I'm troubleshooting. There is a lot of emphasis in visual low-code programming on the first but not the second modality. There is a third modality for reading as well, which is very similar to troubleshooting but usually can be mostly a subset of troubleshooting.
YMMV, but the way I reason through while I read/write/troubleshoot code are mentally visualized and mapped in very different ways. When I compare what I visualize with the junior engineers I support, their visualizations tend to stop at a much higher granularity level. I strongly suspect that I engage in techniques that would be extremely familiar with and be on far more elementary level to those who practiced building "memory palaces" [1].
I have tried to teach this to the junior engineers, but the vast majority are simply wired differently it seems, and the few who "get it" do not sufficiently make it a habit to internalize it, much of which at first involves tedious pencil and paper.
I remember as a kid while blundering about a PDP-8 drawing on paper what I thought was going on at first with labeled boxes and lines (most of which was laughably inept and naive), then gradually transferring that to memory. Over many years of practicing that, it eventually became a reflexive habit. For more difficult problems I encounter today, I still sit down with pencil and paper and diagram it out to talk myself through it and build up a mental model.
For me personally, engaging spatial, motor, visual, verbal, and auditory senses together makes up my "visualization" in an iterative process that gradually internalizes into a pure mental model. That's why I prefer to look like a mental patient in the confines of my private office than at a co-working space or coffee shop.
[1] https://en.wikipedia.org/wiki/Method_of_loci