Dapper Snapshotter Updates "modified" Properties rather than "changed"

Instead of Full Change tracking simply knowing which properties have had their setters called since the object was were returned by a Dapper would be a great feature.

If you retrieve a fresh object from the database and explicitly set a property, no matter what it should be issuing an update statement for that column when persisted . Dapper Snapshotter only looks at "modified" properties, instead of "changed" properties, therefore it may or may not issue and update for the column depending on original value held in memory. This is usually fine if concurrent connections are not updating the same columns or performing pessimist locking, however it can cause issues like:
Client A fetches a column value of "Monday", Client B Updates the column to "Tuesday", then Client A sets the value on the object to "Monday" then performs an update, the outcome would be "Tuesday" even though Client A was last, this is because the Snapshotter thinks nothing has changed as the memory value is stale.

This causes unexpected results especially when implementing HTTP PUT requests that should replace the entire resource. A great explanation of this exists at: https://blog.jooq.org/2017/06/28/orms-should-update-changed-values-not-just-modified-ones/

Has anybody encountered any similar race conditions at scale? I was thinking of rolling my own Proxy implementation to keep track of calls made to setters as I can't see to find anything that suits my needs.

Start by reviewing Dapper Snapshotter's current modified-property tracking and the issue's proposed distinction between modified and changed properties. Compare the behavior with the HTTP PUT and concurrent-client scenario described, then define how setter calls and persistence updates should be verified; no file or test is named in the issue.