We can easily replace a FOR loop with a WHILE loop and vice versa and most features are retained in a reasonable and expected manner. (For example if there is an indicator wired to [i], it will still be connected after replacement).
There is one annoying exception: The conditional terminal is completely ignored.
For example:
Case 1 (FOR -> WHILE)
We have a FOR loop with a conditional terminal wired to a boolean condition. If we replace that FOR loop with a WHILE loop, we probably would expect the conditional terminal be still connected in the same way. This is not the case. We get a dangling broken wire and a new, now disconnected conditional terminal.
Case 2 (WHILE -> FOR):
We have a WHILE loop and replace with a FOR loop. If the conditional terminal is wired to some real code, it should automatically retain the conditional terminal in the same place. (If the conditional terminal is not wired in the while loop, the FOR loop should not show the conditional terminal).
As a practical example, let's look at my old inverse erf draft posted here long ago. One flaw is the fact that there is no limit on the number of iterations so it might get stuck with a misbehaving function. In the old days, we would add another comparison with [i] and OR to the termination condition (lots of extra code, new loop needs to grow in size). A cleaner solution is to replace the while loop with a FOR loop, leaving the conditional terminal in place as-is, and wire a reasonable iteration limit to N (little extra code (just one diagram constant!), loop can remain at the same size). Here Case 2 would simplify the transition.
SUGGESTION: If we switch loop flavors using the "right-click..replace" mechanism, the conditional terminal wiring should be retained in a reasonable way.
