Peter,

>There are more than enough situations where speed isn't an issue at all, for example if it's not in a million times loop. Even in a SQL-query it's okay, as the substitution is done only once by vfp.

In SQL-query it's okey because VFP doesn't offer any other way to build and execute dynamic queries.

>Harder to read? Which one is harder to read? I can't see an essential difference.
>

>&lcString = &lcDir
>STORE EVALUATE(lcDir) TO (lcString)
>

The first line (with macro substitution) imposible to decode w/o knowing values of both variables because variables in macro substitution can include any valid code.
The second line (w/o macro substitution) is clear, value of 'lcDir' expression is stored into variable/property represented by 'lcString' value.

>Maintenance issue? Tell me...

If you've something to say, say it. I supported enough code written by other programmers with unnecessary macro substitution to know what a nightmare it is.

>
>The core point is that AndersH may have (had) a feeling that macro substitution is not a proper programming technique. Statements about performance penalties have been abundant in the last decade and still have their impact on many programmers. I challenge those judgments and think that they're obsolete.

My point is, that there is no reason to use macro substitution if code can be written w/o it.