"Undo" only makes good sense in an app where each user works in her own isolated sandbox. This is a common paradigm on the desktop (e.g. word processing), but less common on the web. As soon as Alice's transaction is visible to Bob, making it undo-able gets much more complex.
We, on HN, all have an idea of the tech behind this, but to the user, it is still perceived as an undo action, and that's what I believe the point of the author was.
It's not job cancellation, your view is such that unless you undo, that's reality (you can confirm this by browsing in a separate window, your non-undone actions have taken place).
What Google is doing is (at least for deletes on mails) is equivalent to a database transaction rollback. So they have a tiny (likely 1-entry) transaction log that they keep per user, and if the user desires, they can use it to fully reverse any operation that is undoable aka reversible.
I suppose it works different for email sends you can undo - in that case it is job cancellation.
Doesn't Drive, just like Dropbox, simply version everything similar to a source control system?
Using the optimistic locking pattern, this would mean that Alice could undo, and if Bob then makes changes referring to Alice's entry, it'd be pointing to a previous versioned entry (Alice's undo would simply copy version n-2 and make it version n while Bob would be pointing or editing version n-1)
Not sure. That behaviour would be a little weird, if Alice hitting Ctrl-Z undoes what Bob just did. Google Drive's document editors explicitly appear to support "undo".
