Let me start off with appreciating your sentiments. VL is hard, confusing and sneakily expects a lot of code prowess to actually become useful. A gui that fragments the understanding of dataflow, the sorry state of ioboxes, the weird node browser and the lack of tutorials/help patches are not helping either.
If this sounds bad, it will get worse, even after you screamed wtf at your screen for the first time. Some core node libs are not homogenous (try replacing a Damper with a OneEuroFilter), and the general immutable approach will put extra pressure on you to always write back changes.
That is my standing with vl right now, after a hefty 5 week climb of its learning curve (@h99 don’t feel bad because other know more, I have had the pleasure of some vl testing as early as winter 2015, so never compare).
I am finding that vl is not finished yet. It will need a lot of work to be as productive as vvvv, because right now vl still makes fire with sticks. In a damp forrest, if you catch my drift.
With that assessment up front, I can assure you that most of your actual concerns are temporary.
The Pads with equally named Inputs/Outputs are your datatype definition, like a Formular for Messgae (if you are familar with that). At first glance they seemed awefully odd, but because they are very visual and quick to make (Ctrl and Shift are your friends), they grew on me quite quickly. The pattern is clear, and it will make click.
The state is a whole different issue. It has been a vvvv issue all the time, even if you didn’t know, and in effect a vvvv user was forced to keep a steady spreadcount if things were to run smoothly. This limitation was inconsequential for most visual experiments, but it was always a brick wall, when trying to patch a more flexible thing according to professional requirements (like multitouch, or something involving game elements). and it seems certain that vl needs more of the high-level nodes again to mimick the easy vvvv flow.
VL is a language rather then a replacement of vvvv, So it will take some years till all appropriate libraries will be brained out (hopefully with help patches). Please mind that it took 4 years of the devvvvs life to brew the language (and the gui, and the parser, and the IL compiler, and the error reporting, and the importer, etc…), and my humble opinion is that its concepts are epic. Epic enough for me to torture myself with it. What’s under the hood of this thing is an enourmous achievement.
But don’t let yourself be fooled by the confident answers of @tonfilm and @joreg. I am sure they are struggling with finding useful patterns, best practises and practical explanations just as you are. If you need a joke: Devvvv’s been so much under the hood of their vehicle, they must have missed out to drive it ;)
When I started vvvv (beta12 or so) doing projects was like making fire with some loose branches, in a damp forrest. There was not even a node browser, and spreads were just that, there was no Bin Size anywhere except on the GetSlice. But vvvv grew, and its versatility. Community input, contributions and new features from relentless devvvvs made it better. Standard patching patterns and avoiding the pitholes made patching experience more fluid, and less frustrating. Learning about dark secrets of vvvv (like state, binsize, limits of s+r, dangers of framedelay) made patching less error prone.
Of course, there was nothing more versatile to compare it to (unlike vl now), so accepting faults was much easier back then (for me personally, accepting that was not an option, so I started grinding the sdk, but that is another story).
But give VL some time, and your openness. Do it like you did it with vvvv: read girlpowers, and try to understand. Tinker. Learn keyboard shortcuts from the grey book. And keep your stuff in vl as much as possible, avoid making a family of vvvv nodes for your project, even if tempted.
It will take bright minds to build up vl to the state where vvvv is. The “easy” nodes of vl might look very different from the easy nodes in vvvv, but they will come. The current state of vl is neither a chicken nor an egg, but it definitely has the power to eventually fulfil its promise.
It will take concious patchers, that put in extra effort to highlight bugs, and share their experience (both the frustrating and the godspeed ones).
It will take great effort of the devvvvs to manage a friendly ecosphere and help with tools, advise and stellar open source attitude to add well-patched community code as quick as feasible.
And it will take a lot of teachers, who are ready to rationalize their own understanding so others can partake.
So to close this non-answer: learing vl is hard, and the current state of it makes it sometimes brutal. Own mis-conceptions about the nature of a patch clashing with the reality of regions will leave you confused and even frustrated. I can tell you that some will vanish (because regions are awesome, especially the foreach). Some other things might not, because they are not as well designed as they could. Both sides need to be valued here.
I am still confused about vl concepts myself, and dissatisfied by the lack of many essential nodes, but I am sure with enough curious minds we can eradicate those for future generations of patchers.
Please continue threads like this. We need more talk about shortcomings and user stories, if we want VL to progress: At this stage we should discuss visions and preferences, as much as small design details and frustrations. It will be a way to become better patchers ourselves, and make vl better for future patches.
Because eventually, every knowing hand helps.