Matching NEXTs to FORs

Imagine you have a program (some code) END ' >> Section 1 >> @Some_label (some code) GOTO @somewhere ' << Section 1 << ' >> Section 2 >> @Another_label (code) GOTO @someplace ' << Section 2 << In *EVERY* dialect of BASIC I have encountered, if you were to switch "Section 1" and "Section 2", the behaviour of the program would not be altered. Not so with SmileBasic. FOR A=1 TO 2 FOR B=1 TO 2 GOTO @NEXTB @TESTEND END ' >> Section 1 >> @NEXTB PRINT "@NEXTB",A,B NEXT GOTO @NEXTA ' << Section 1 << ' >> Section 2 >> @NEXTA PRINT "@NEXTA",A,B NEXT GOTO @TESTEND ' << Section 2 << Run this program, and you get the expected output: @NEXTB 1 1 @NEXTB 1 2 @NEXTA 1 3 @NEXTB 2 1 @NEXTB 2 2 @NEXTA 2 3 Switch the order of "Section 1" and "Section 2", and you get @NEXTB 1 1 @NEXTB 2 1 @NEXTA 3 1 @NEXTB 3 2 @NEXTA 4 2 It appears, before the program starts, every NEXT is associated with a FOR: that is, the FOR that it would normally be associated with if the flow of execution were always from one line to the next, no skipping, no going back. That will work, most of the time, but not all of the time. I believe this behaviour is the result of another design decision made by SmileBasic that is different from every other Basic: that a FOR loop need not ever execute. Someone made the decision to deviate from a constant feature in ALL OTHER BASICS, and as a result, this bug. Poor design decisions are evident... again.