In similar circumstances, I have experienced the fastest and most flexible combination of performance with SCAN as follows:

1. An index order is set.
2. There are usually several (or many) records that match a desired index value or range of values.
3. Of those records that fall in the desired range of index values, some additional criteria in those records is used to determine if each record is a "hit" or not.

In these circumstances, the following construct, as shown by example, seems to run very fast:

Set Index to Age
nMinAge=30
nMaxAge=40
#DEFINE AdditionalCriteria  Salary>100000 .and. Sex="F"
SEEK nMinAge
If Found()
  SCAN REST WHILE Age<=nMaxAge FOR AdditionalCriteria
    && This loop runs very fast
  ENDSCAN
ENDIF

The WHILE clause has precedence and follows the index order. The for clause acts like a filter while the WHILE clause is satisified. When the WHILE clause is not longer satisified, the SCAN terminates. If you know ahead of time that many records meeting the WHILE condition will not meet the FOR condition, then you will actually save time using a FOR condition even if you need to completely re-use the FOR expression as part of a calculation within the SCAN loop. This is because VFP is efficient at how it compiles and applies the FOR condition of a SCAN loop (even without Rushmore) versus *not* using a FOR clause, and instead trying to apply the same logical expression/calculation inside of a SCAN loop with an IF statement.