The whole change/update tracking got to be such a headache for me at some point that I decided to implement pessimistic locking in all of my apps (thousands of them), and so far noboby has complained. Quite on the contrary -- as long as the users have enough information about who has the record locked and how long it has been locked and how to reach them, the users are fine about bugging each other to "get off my record".

VFP3 introduced the View with optimistic locking as its default state and change tracking by default. It worked well and eliminated all the rlock() code and contention management. IOW there was less code, not more.

The second issue was the rise of the stateless application, such as a web app. Consensus was (and is) that pessimistic locking is infeasible in these circumstances.

If you must allow simultaneous access due to some time-critical and update-conflict-prone data, then you need to implement granular, column -level rules about inter-relations between data items and potential RI problems between related tables if you plan to allow a partial (or selective) update on top of a previous update. Not a good candidate for a generic solution, that.

Sounds dire. Can you provide an example? I cannot think of a RI problem caused by selective updates, as long as the standard principles are followed: system-generated primary keys that cannot be edited, triggers if changes need to cascade and transactions if work needs to be done that doesn't fit in a trigger.

I know that optimistic locking and the resulting programming mess is sometimes a necessity...

What programming mess would that be? If you update edited fields using a where clause consisting of the primary key, your chance of success is as good as can be. If you use VFP Views, that was done for you automatically. I can understand why you might see a mess if you used compound or human-editable keys... but that's a separate issue.