I quote from the VFP help file on the REPLACE command:

Note   If the IN clause is omitted, no replacement occurs
if the record pointer is at the end of the file in the current
work area and you specify a field in another work area.

Huh? .... it's true...just try it...

select table1
replace table1.c with 'A'            &&init value
select table2                        &&new workarea
locate for .F.                       &&go eof
replace table1.c with 'B'            &&try it
?table1.c                            &&yeilds 'A'
go top                               &&go bof of table 2
replace table1.c with 'C'            &&try it
?table1.c                            &&yeilds 'C'
locate for .F.                       &&eof table 2 again
replace table1.c with 'D' IN table1  &&try it with the IN clause
?table1.c                            &&yeilds 'D'

Would anyone like to explain the origin of this FODU ('feature of dubious utility') to me?

Let me guess - if you fall off the end of a parent table, VFP is preventing you from altering the related child ... well fine. Then only apply the rule when the two tables are related (or better yet ... just write into the void).

I got nailed by this obscure feature and I feel very lucky to have discovered the fine print at the bottom of the REPLACE help before spending hours trying to figure out why the replace wasn't happening.