I agree that it will important to add different kinds of loops that are specialized for certain collections, but the first implementation needs to be the most straightforward so we can build out from a baseline. I foresee exactly the kind of loops you describe using the same infrastructure packaged in different ways.
With the addition of the “Iterations” parameter at the Genome modifier level, we now have control that looks like (courtesy of Bobo):
FOR O = 1 to Iterations DO
FOR M = 1 to NumberOf(Verts/Faces/MapVerts) DO
FOR L1 = 1 to MaxIterationsLimit WHILE Condition == TRUE DO ...The O loop is controlled by a spinner (future development will make that optionally a per-object magma expression). Changes to the mesh will be “seen” across these iterations. For example, if you changed the FaceSelection in one iteration the second iteration will report the new value when evaluating the InputChannel(FaceSelection) node. Previously you could achieve a limited form of this effect by making multiple instances of the same modifier on the stack.
The M loop is the same 'ol standard Genome loop over verts, faces, or face corners we already have. Since we are adding access to neighbor verts/faces/etc. we now make a copy of data that is both being read and written to in the expression, so that reads are never affected by the writes within the same M loop.
With the addition of a Loop node, you get the L1 (and L2, and L3, … L# nested) loop expressions that are terminated by the user writing a Bool value to a pre-defined Condition output. Any reduction expression (ie. one that only writes to a non-array variable) can be created with these. Individual evaluations of the loop can execute varying times depending on the input values and the contained expression. I envision common usage situations to include:
[]Root finding (ex. Using a texmap as a levelset and moving the evaluation point along a vector until you reach 0)[/]
[]Summing/Combining data over all the faces that connect to a vertex[/]
[]Allowing us to work with polygons instead of triangles only (ie. we can loop over the N vertices per polygon instead of assuming 3 vertex triangles)[/]
[]Tracing trajectories with multiple bounces (ex. Raycasts for lights, particle trajectories after bounces, etc.)[/]
[]???[/]
[]Profit[/]