Translation- It only updates the very first loop node.
So if you send 1-5, nodes 2-5 are not updated. - On top of that, looping on nodes 6-10 (loop #2) actually modifies node 2 instead.
Nodes 11-15 (loop #3) modifies node 3, 16-20 (loop #4) modifies 4, and so on... - There also seems to be a bug if number of total nodes being looped on is not divisible by RecordsPerIteration.
If there are 50 total nodes:
Valid: 1, 2, 5, 10
Invalid: 3, 4, 6, 7, 8, 9 - For the invalid ones, the final iteration uses the wrong name for the path of the parent.
For example, if _LoopNode/WorkData/DatesList/Output/Result/Date is the correct path, then the final iteration somehow creates it as _LoopNode/WorkData/Date/Output/Date
DatesList was renamed and Result is missing entirely.
Loops are mainly meant for looping on one record at a time. This makes sense when we're looping one at a time over a total of like 30 records.
But when we created loops, we recognized that during batch jobs, when working with large amounts of records, doing one at a time might be too inefficient and our already built batch jobs are doing things for like 10 or 50 at a time. Then the logic in the loop would be built to handle multiple at a time.
We knew this was an advanced case, but one that our developers run into for EC that see a lot of addresses/items. At the time it was introduced our complex batch jobs were already built, but we said if we wanted to do them again without having to create our own loops, this would have helped.