On the one hand, I agree with the ideas here. On the other hand, it really worries me when I find out that some server doesn't delete the data when I tell it to delete it. For example, when you delete your Facebook profile or your mails on GMail, wouldn't you like that data to be utterly destroyed?
What would be the correct solution, the one that balances out both of these needs?
Gmail's "undo send" functionality faces a similar but different problem: once an email has actually been sent, there is no way to undo it. They way they solve that is by letting you configure a delay, so you have some period of time in which the email hasn't actually been sent yet so you can undo it.
Something similar could work here. When you delete some data, it gets soft deleted (still exists in your database/etc, but is considered deleted by the application). After a matter of minutes (hours?), it gets actually deleted. You've got a grace period in which you can undo the delete, and then it's gone forever.
Since the most common use case for an 'undo' feature is undoing something you did very recently, that should strike a good balance.
Presumably something similar to the Gmail "Undo Send" example? Time limited reversal (in this case specified by user preference) to give you at least some amount of time to reverse your actions before they become permanent.
It's 5/10/20/30 seconds for an email, which seems like a good fit for that use case. Perhaps a Facebook profile delete or mail delete might be more like a 5 min/1 hour/1 day option set, since it doesn't interfere with the primary purpose (i.e. I wouldn't want to wait an hour for all my emails to get sent, but I might be OK waiting an hour for them to actually delete).
What would be the correct solution, the one that balances out both of these needs?