1) May I suggest this is a documentation issue more than anything else.

SELECT SomeAlias
SCAN
...
ENDSCAN SomeAlias

We cannot anticipate what may fail in some version of VFP. So adding the SELECT before the ENDSCAN just because VFP may possibly fail is a weak argument. By adding SomeAlias to the ENDSCAN we document what the intention is while avoiding an extra line of code and while following the (VFP9) documentation:

"You can place comments after ENDSCAN on the same line. The comments are ignored during program compilation and execution.

SCAN ... ENDSCAN ensures that, upon reaching ENDSCAN, Visual FoxPro reselects the table that was current when the SCAN ... ENDSCAN loop began."


>>>We have seen Fox not behave in the default either when a lot of recursion is used so we code against the improbable and put SELECT at the end of a SCN-ENDSCAN.
>>>
>>>Say what you want Fox isn't right all the time.
>>
>>I assume you mean iteration where you write recursion. Anyway, I think you make a big mistake here. You are suggesting that Fox does at times not select the right workarea when redoing or leaving a scan. I feel sure that you cannot even provide us with one such example. I think that wrong code must have been the cause of what you guys say to 'have seen' at times.
>
>I think there may have been a bug in one of the early releases of FoxPro when SCAN/ENDSCAN was introduced. You know, back in the days of the different releases being only days (or hours!) apart. Whatever, it certainly wasn't a bug that lived very long.