It's not case-insensitive. Try it. I knew they had the case-flipped version but I didn't know about the others. Why would a user's password have an extra character on the end anyway?
That seems the strangest of them all: "If the login fails, try stripping a character off the end and see if that matches". I can understand the "First character inadvertently capitalized one" somewhat, but the CAPS LOCK thing seems unforgivable. I just did that yesterday with Apple and it simple suggested to me caps lock might be on. If your test for that is (password didn't match AND all alpha characters in the submission are capital letters) you don't even need to store a second hash for it.
I know there will always be trade-offs between security and UX but, if this image is accurate, that seems like going too far in favor of usability. No matter how small, multiplying the numerator in the probability of matching a password is a dangerous decision.
Frankly I can't remember the Windows approach ever being useful to me, and more often than not it bites me in the ass because I habitually hit something like shift-i to type "I" and end up with a lowercase i instead.
You don't need to store a second hash for any of these; just transform the sent password with (invert all characters, invert one character, delete last character), rehash it and compare it to correct.
Whilst it does increase the numerator, it also allows Facebook to decrease the number of obviously wrong password attempts permitted before taking additional precautions. Since these are overwhelmingly likely to be user error, I think it's a perfectly reasonable tradeoff.
Not really.
(The other ones aren't strange either, but I admit I have never heard of this practice.)
If you have the password stored in Notepad and there's a space behind it. Or you already have a space behind it, and then entered it. Or it is a DOS document you copy/paste from. Quite common. But I suppose the other 2 are more common.