What happened OR Why $Record_Prior is my best friend

Topic: Be as specific as possible in your criteria.

Example: Every time a Lead is “Closed – Not Converted” we want to send an Email to the customer thanking them for the nice call despite not buying.

Quite a simple requirement, we all have built them a thousand times. 
And I’ve built them wrong so often until I embraced the “$Record_Prior” (Priorvalue) concept.

Instead of asking:
1) “What should the Lead look like to trigger the email” 
I’d ask now: 
2) “What happened to trigger the Email?”

Number 1 leads me to the following criteria:
Record.Status = ‘Closed – Not Converted’

While Number 2 leads me to the better criteria
Record.Status = Closed – Not Converted’ &&
Prior_Record.Status = ‘Working – Contacted’

Sales tell me after they talked to the Lead and determined, that there’s no interest to buy the email should be triggered.
What happens after the Lead.Status = “Working – Contacted”.

What’s the big difference you ask?
While the first solution works for the time of releasing the feature, you pass all tests, and everyone is happy.
In but long term, the logic is brittle and can have unexpected side effects. 
A simple mass data update from “Open” to “Closed – Not converted” can trigger lots of emails without anyone expecting them.

I know it’s more time, to ask “What happened” but I think it leads to way cleaner solutions.

I try to write my criteria for anything to happen as strictly as possible to avoid any unexpected side-effects down the line.

PS: The same applies to Validation rules (Priorvalue) and Triggers (Trigger.Old).

PPS: I still feel sorry for the thousands of customers who randomly received french SMS because I accidentally triggered a send-out during data migration.