This is not a definitive answer, just some thoughts.
1. Client-side hashing.
I see what you're going for: protecting the plain-text password. An idea like this relies on every site using a different hashing scheme (otherwise you can make lists of which sites use the same hashing scheme and know that their hashes / passwords will be interchangeable).
So I guess this would help a little, but certainly doesn't solve the problem, and relies on devs changing their hashing schemes from the default (which is dangerous for other reasons if they don't really understand how password hashing works).
2. Zero-knowledge proof based on password
I am not an expert in Zero-knowledge proofs, but my understanding is that they are a subset of Public Key Algorithms. Symmetric-key algorithms (like AES encryption) can easily be combined with passwords ... public key, not so much. My intuition is that if you flesh out this idea fully, you're basically going to re-invent client-authenticated SSL, so just use that?
IMO passwords as a whole are a sinking ship; they are a broken system. This is because we are at the point in history where hacker's ability to brute-force passwords is starting to surpass the human brain's ability to remember complex passwords.
Rather than trying to patch a sinking ship, I suggest that we (as an industry) move as quickly as we can to adopt non-password-based auth systems. Things like 2FA or ssh keys do not have the same fundamental problems as passwords, and are the kinds of solutions we should be embracing.
P.S. At time of writing, the question has 3 close votes as "too broad". I've done a dangerous thing here where I edited the OP's question to be less broad, then posted an answer to the newly-worded question. I hope this is acceptable.