I recently converted some generation code to use a plan, so you can make a plan and then execute the plan. Architecting your code this way gives you things like dry runs and rollbacks for free; I feel like diff storage is in a similar realm of usefulness.

Timestamps are a huge observability win relative to the amount of effort they take. "When" will give you hints to pull the other information out of logs etc. What you're proposing is better, but is a heavier lift; if you have capacity for that, awesome, if you don't, timestamps go a long way, take very little time to implement, and not having any information will really sting.

I think this may miss the point of the article, which is pointing out that you can get a lot of value for very little effort by using a timestamp instead of a boolean. I don't think it's intention is to replace a complete change history/audit log implementation, which would require a significant amount more time/effort to implement.

Sure - this is objectively better for tracking/auditing, but... now we're getting back into trade-off territory.

Where is that change history stored? How much data are the diffs generating? Are we deriving the final state from the log, or can the log the and record disagree?

Basically - this is now back in the "What is this history buying us?" realm, not in the "easy win" realm.

In some cases it can be absolutely worth it. But probably not all.

Sure, but now you REALLY changed the game.

If you're currently using a boolean, switch it to a timestamp. There are no real world downsides.