I tried to figure out if the same behaviour would occur on a "simple" delete.
Basically I thought that maybe it does
FOR EACH Record_in_the_Scope
RLOCK()
See if it matches criteria
Update (Delete) if necessary
UNLOCK
ENDFOR
for *any* scope after rushmorizing it.
The idea being that in the "2nd join" case this scope is entire table.
So I tried to execute DELETE on a *partially* optimizable WHERE condition like this one:
DELETE FROM Resource WHERE MainId = 12345 and Type="1"
where MainId is optimizable and Type is not. I thought if I RLOCK the record that matches this criteria by its MainId part but doesn't match its Type part, I would see the same behaviour when VFP would try to attempt a lock because my record is within the optimized part. Well, it didn't...
And of course since DELETE is just an update of a special column, UPDATE command is no different in behaviour.

I don't know what to think now. I mean, other that it is a bug.