Regarding activate_user(), I don't see what accepting a password (as a GET parameter upon page display) would bring. Making the user choose a fresh password (and otherwise suggesting one) upon activation makes sense though.

The user edit change, especially requiring the old password, makes sense, but isn't important while moving to password hashes. But it should be possible to also put it in while we're looking at the code :).

Everything/HTML.pm::confirm_user is the code called for every page that looks at whether the supplied cookie actually matches a hash of your credentials. So your password is not stored in the cookie, but basically you get a session key, albeit one with unlimited validity. Your fallback to doing the validation through the password directly is more or less what's done now, except that the cookie is using a hash, and the same hash is rebuilt from the password.

Thanks for looking at the changes and giving them critical thought!