Yeah i was hoping for such “Loop frames” too such as H.
I think the inconvenience of the proposed “Loop group” is that it is forcing us to create nodegroup even when it is not necessary. Nodegroup are kind of a burden really, we are forced to pack all our arguments + it might create useless data block. Also accessing named attributes from a nested nodegroup is quite difficult currently. But this perhaps is a separate issue due to the named attribute design.
I really do not like to work with nodegroups, as most of the work is spend on creating and managing input/output sockets. With more freestyle work and a lots of nodes this can be a chore. I almost always use node frames to clean the node workspace.
I wish for group and frames integration in such a way that a nodegroup could be viewed in two ways - one as it is now and the second view could be like a frame. This could simplify managing group inputs and outputs.
I agree that “Repeat” is the best name for repeating; I wasn’t suggesting changing the name for the repeater node. 
It’s the other node type (“Geometry Loop”) in the proposal that I was proposing a different name for.
“For Each” felt like a logical name for it to me, because its purpose seems to be for repeating the same operation once for each item in a list, like for each vertex, or for each edge, or for each mesh, etc. Hence, “For Each”. If I’ve missed something then feel free to disregard though!
I just need to be able to do
for face in geometry.faces:
p1 = geometry.vectices[face.vertices[0]].co
p2 = geometry.vectices[face.vertices[1]].co
p3 = geometry.vectices[face.vertices[2]].co
if len(face.vertices[0)>3:
p4 = geometry.vectices[face.vertices[2]].co
else:
p4= Vector([0,0,0])
add instance at face center and use data to align / stretch / skew it
and something similar for edges.
Oh, yes, node, that repeats for each input item will be great too. We already have selections to Slice the range/list of items.
Maybe I have this wrong, but is there a reason to give “Geometry Loop” a name at all?
Available GN groups are displayed in the Shift-A -> Group menu, when adding a group that has published fields it would “just work”.
So why the name at all?
It can be the built-in behaviour of GN in Blender.
If a group has published fields, then Blender itself would add a ‘selection’ field to the group node. Considering that the iteration of the group is controlled outside of the node, I don’t understand why it needs to be a special “loop” node.
Groups are from a user POV iterated already, right now we just can’t control the individual non-field aspects of the group composition.
I possibly have this part really wrong:
Why not have selection as a publishable input parameter in the child group as well?
And pass that value into the group, and allow the user to do the maths inside the child group?
My gut feeling is to use the current 3.1 GN model as much as possible, without having to resort to custom nodes.
Build this behaviour into the very foundation of how GN works.
Or possibly “Instance on Points” for example could feed the selection back into the connected instance?
It is a good news that advanced topics like looping are being discussed, the proposal has almost every corner about loops covered, so I will just list my suggestion below.
Hello,
pretty exciting proposal, I can’t wait to start having loops.
A few quick remarks:
The simple Loop seems pretty straightforward, the Geometry Loop seems to have pretty steep learning curve.
It seems the Geometry Loop is a proposal to replace the “Geometry Field” which makes it essential in terms of functionality.
The “Element Geometry” and “Evaluate at Element” feel a bit of a patch-solution to the strictly abstract approach of the rest of the system.
As a user, I would wonder why is it so different to instance objects on a grid, than to instance slightly varied objects in a grid?
It seems like previous workflows should’ve worked like a loop all along but now we are forced to invent a different workflow in order to break the restrictions of the previous, abstracted system.
Also, having a loop which depends on the use of additional nodes specific to that loop, already increases the difficulty of using it by a ten-fold. It’s a bit of an obscure workflow.
I don’t have better answers right now, but this is my first impression.
If this produces variable “clones”, is it possible to instance the clones that are identical, for most efficiency? For example, on the example with the random circles, if we produce four 3-segment circles, and three 5-segment circles, can these be instances of a 3-segment and a 5-segment geometry?
Can we use a “Threshold” limit for a loop, like a “while” loop? We could still have a maximum amount of iterations to make sure we don’t create infinite loops.
Overall it’s a strong start, thanks for making and presenting this proposal!
I don’t think you should tie the loop domain to the logic whether the results per element are independent from each other. I’m thinking of distributing some points on e.g. a tree stem to seed branches. I would want to iterate over all points sequentially, so I could grow the branches non-intersecting. Having the first branch accessible in the growth of the second would allow to grow around the first one. Having all branches being evaluated in parallel you can’t prevent them intersecting.
Similarly the interval based loop you described before shouldn’t necessarily be a serial loop.
Maybe I just want to create 10 different versions of something, that I scatter afterwards to thousands of points. Those 10 elements would be independent and could run in parallel. I wouldn’t want to use a geometry loop to create thousands of individual geometries for each scattered point, but first create a sufficient number of geometries to scatter and reuse them afterwards.
About the geometry loop, I think it would be nice if that one could get an input field for elements. This one should be a discrete valued field and the geometry loop iterates over all pieces with unique values of that field. This would allow to iterate not only over e.g. single triangles, but maybe groups of 10 triangles. Or you provide e.g. a node, that computes a field assigning topologically connected pieces their own id.
I feel like I’ve come a little late to this party ( Australian timezone and all!)
As a programmer, I would like to see an implementation for the 4 basic loop types:
It might be handy to look at a separate Loop node for each type with a parameter of the loop node being a node group (name). This way, the main flow can be kept clean and loop “code” groups can be organised elsewhere in the Note Group screen (Or indeed in a different Geometry Nodes instance for re-use)
Selecting the Node Group would add the In/Out connectors from that group to the Loop node, customising it and allowing parameters to be passed in and results out.
Recursion could be handled in this way by placing the Loop node inside the group that it references.
The more complex the things you try to do with nodes, the more unwieldy they become.
One thing that would short-circuit the need for a whole lot of different node types would be to implement a “scripting” node, analogous to OSL nodes in Cycles shaders. Depending on the performance, you might even getting away with letting the scripts be written in Python.
I think that, in terms of UI/UX, there is no reason to go back to old groups with their tiny fields to name sockets.
We could imagine an easier socket definition without going to sidebar. Like selecting a socket and then, calling a menu to rename,change its type or call a floating panel to set its limits.
We can imagine shortcuts to add or remove inputs/outputs sockets.
As it was said, reflex would probably to create a group, first.
I imagine that operators to convert a nodegroup into a loop could be a valid way to create loops, at low cost. Conversion could abort with warnings when nodetree would be irrelevant for a loop.
I agree with BD3D. A different icon + a very different color (violet, brown or orange) for label should be sufficient to avoid confusion. Color could be to tinted background of editing view.
It looks like point against using nodes similar to groups is the way to create and edit them.
IMHO, making loops as frames will not help those people to benefit from nodegroups advantages.
The solution to that is rather to create a “frame-like” display for nodegroups and loops in between default and editing display.
Of course, basic loops and basic groups should probably be added to official Node Presets addon.
Can’t wait for the first flavor of Loops. (the sequential ones)
Especially to build strange attractors 
Having as a return value not only the last iteration, but maybe a list of the iterations may be interesting in some cases (scan vs reduce). Scanning a list of vector 3 and using them to set position based on vertex index may be an option. Guess building a point cloud can also be done including a join node inside the loop, and passing along another vector 3 output as input. Some existing node addons such as svershock or animation nodes have been dealing with lists, don’t know if lists are a whole different direction as fields and are never supposed to be implemented. If ever they are a thing at some point, really think a “scan” option may be useful.
Can new field nodes specific to loops be used instead of “evaluate at element” be used. A “Loop element position” or “Iterated face” may be more straightforward to understand.
“Loop” vs “Geometry Loop” is vague. The names need to differentiate how they operate.
Maybe something like:
Loop set (number of) Times
For
Loop per Item
For Each
Let’s not re-invent the name of the wheel
Programming terms are not that understandable at first glance for some who don’t use that function, a more “accessible” name is desirable/understandable .
In that específic term I would say is pretty straight forward, for n times, for each element, not weird
Geometry node is already visual programming tho 
so the arg of “Programming terms are not artist friendly” is a bit weak IMO
it’s important to remember that this kind of system audience is more advanced than the norm
imho GN should ease “the norm user” to get into programming
my students learn much quicker using nodes than scripting, and learning fast means building interest
It’s been clear many many times that GN is not for new users or “norm” users, that does not mean that it cannot be used, but it’s not the target and should not limit GN or define what terms are used
