It is true that most diagrams that you write in G will have a degree of parallelism that is fixed and determined at the time you draw the diagram. Coming up with techniques that overcome this static degree of parallelism in a diagram has been an interest of mine for a while. (I'm a long-time developer on the LabVIEW R&D team at NI.)
My classic example of the problem is a network server that needs to be able to scale from serving one to thousands of clients simultaneously. HTTP servers typically do this by spawning extra "handler" threads (or even processes), each of which handles a single connection to a client, then quits (this is a simplification, but suffices for this conversation).
To help address this problem, we introduced (around LabVIEW 6.1) a new feature of the Open VI Reference function and the "Run VI" VI Server method which allowed you to open references to reentrant copies of a "handler" VI and run them independently without waiting at the "Run VI" method invocation for them to finish. In essence, this is spawning a new thread of execution. (You could actually do something like this prior to LV 6.1 by using Template VIs and making complete copies of the "handler" VI. This is more heavy handed, but works, and I believe is the mechanism still underlying the existing Internet Toolkit HTTP server.)
You can find an example of using the 6.1 feature in LabVIEW's examples folder: examples/viserver/runvi.llb. (Unfortunately, the client VI of this example has been lost somehow, but you can see how the server is programmed.)
This mechanism has its drawbacks. For one, passing parameters to the "handler" VIs is clumsy because of the "Run VI" VI Server method's interface and semantics. For another, there is a fair amount of "mechanism" that you have to code up - not a lot, but it is distracting and not really relevant to the task at hand. We have considered and drawn up some ideas that would simplify all this, but they are not really ready for production.
Your comments regarding "parallel 'for' loops" are interesting. We have a few ideas along these lines but they, too, are just in the brainstorm phase.
Your other comment regarding why this is an important issue is right on the mark, particularly the expected movement towards multicore processors. The Intel Core 16 HexaDecimo processor is probably only a few years down the road. Running on clusters of processors is conceptually similar but introduces a good number of new problems involving cross-processor/machine communications.
