SNIP
>*** SECTION 3 ***
>Another thought has just occurred to me, about why I don't like multiple exit points in general. Continuing with the FOR example containing an EXIT, it has to do with what VFP has to do in setting up and breaking down a loop structure internally. If EXIT was not supported, the loop could always reliably be broken down by the FOR statement once the iteration count is exceeded. However, EXIT transfers control to the line immediately following ENDFOR/NEXT. This complicates interpreter design as an implicit loop breakdown must be executed before the transfer of control. Otherwise, undesirable side effects such as memory leaks may occur.
>
>I imagine it would be enlightening to talk to the Fox Team about this kind of issue. One thing we can be sure of, though, is that anything that complicates the interpreter is a chance for bugs to creep in, and also consumes more of their limited time.
>
>Over the years I'm sure the vast majority of these sorts of issues have been ironed out pretty smooth, but I still feel more comfortable exercising the interpreter in the "expected" fashion. Like driving on a paved thoroughfare rather than a gravel back road.

I simply want to point out that I don't think that EXIT/LOOP is in any way a 'convenience' add-on to the FOR...NEXT construct. My mind tells me that I was using EXIT/LOOP in FORTRAN back in the late 60s.
So I'm quite sure that you are right that any troubles have been ironed out by now.
On the other hand, though, I must admit that I deliberately keep my list of commonly used commands/functions to a minimum set, just to help to insulate me from possible 'disruptions' introduced by new versions or SPs. A simple example is that I'll happily code 4 or 5 IF... OR...OR for different values of the same variable rather than use INLIST(). I just feel that a problem with IF is far more likely to be found/fixed in beta testing than a bug in INLIST(). Same goes for lots of other possibilities.

cheers