You're right that it's bad to store non-hashed passwords, but your point about security is unfounded.

Facebook, and any other company you'll log in to, requires a non-hashed password at some point to check against the hash. You need a cleartext password at some point, otherwise the user can't send anything to you.

The best practice for security is to not store passwords in cleartext. You can certainly perform extremely limited actions on passwords in cleartext (like hash checking), and you inevitably have to.

Which brings me to my overall point - as the Facebook security team has explained before on their whitehat page, you do not practically reduce security by allowing caps lock inversion to check a hash.

What you're saying about Facebook having an abnormal process also isn't true either - Facebook does one of two things, both of which are secure:

1. Stores two hashes for each password, one the real password and the other the case inverted, or

2. Checks a password against a hash, and inverts the case and checks again if it fails.

There is nothing about this which is different from normal password transmission in cleartext, and Facebook doesn't store the cleartext password you send them.

EDIT to your EDIT:

No, no no no no, no. Don't do clientside things like that. Allowing a user to directly manipulate something as major as whether or not their password is hashed before it is sent to you is bad. It doesn't even matter that it's just them hacking themselves; it's just bad form to put that in their browsers' hands. Plus, a stored cross-site scripting error that went viral on the login page pre-auth could screw your password database, leading to a layup for mass cleartext password compromise. Or in a worse scenario, you're giving a user direct write access (and then maybe reads) to the password database.

It's much safer to do the industry best practice of destroying cleartext sensitive information upon successful hash.

Say no to clientside security. There are arguments for hashing clientside, but they can all be summed up by "You shouldn't let people potentially sniff users' passwords" - if you implement TLS/SSL correctly, this won't be an issue and the cleartext password will exist briefly, then get destroyed.

The one other argument is that someone could compromise the server handling the hashing process and write a script watching all the passwords. But this isn't a valid concern - if someone has backdoored your login server, it no longer matters if passwords are cleartext for the damage they'll do. The level of difficulty you introduce by having passwords hashed originally becomes moot at that point.

Finally, consider that a client-side hash of a password sent to a server becomes the effective password for that user, not the hash of the password. This means that, effectively, if no other action is done at the server, you're actually then storing the password in plaintext. If a user was MITM'd while sending the password, the hash can now be sent directly to the server in place of the user's password, because it is the de facto password.

The bottomline: client-side hashing offers no real addition to overall security posture under TLS/SSL, and removes most of the benefit of hashing.