I can accept, and it is a good thing, that the low level record based command

REPLACE fieldName1 WITH exp1, fieldName2 WITH exp2

is executed with a left to right evaluation:

eval exp1
put this into fieldName1 
eval exp2 && if this use fieldName1, it use the new replaced value
put this into fieldName2

The UPDATE SQL is a set based command

UPDATE tableName SET fieldName1 = exp1, fieldName2 = exp2

and i aspected that the order of the setting list not influence the result.

Then the implementation it have to compute update values ( like a VFP expression ),
and after set these values within the relative fields,
like this:

eval exp1
eval exp2 && if this use fieldName1, it use the old value
put exp1Value into fieldName1 
put exp2Value into fieldName2

A simple example:
I want swap two fields into a table:
( Is impossible do this simple task into VFP8 without additional operations )

CLEAR
CREATE CURSOR myCursor (f1 I , f2 I )
INSERT INTO myCursor VALUES (1,-1)

UPDATE myCursor SET f1=f2 , f1=f1
? f1,f2, "aspected -1,1"

without

or
- add a dummy field
or, only in VFP9
- do a join with a copy of the same table via a primary key

Another little problem is this:
if you traslate a VFP UPDATE into MS SQL or others backend
the update set work in "independently from the set order".

Of course, exists situations where this bad mode can to be useful,
but every bad or bug behaviour has always some situations nearly where it can be useful.

Why i write this now ?

Because the new VFP9 improvements
they supplied an optimal moment of change,
eventually tying this to SET ENGINEBEHAVIOR 90

Thanks
Fabio