I think the flaw in your plan is your statement
H0 is unknown to the hackers, yet still verifiable by the server.
This is not the case. Remember that hashes are one way. All the server has received from you is H1, which they have converted into H2 (and which is now compromised). The server does not know what the input was which generated H1 (i.e H0). Furthermore, it is assumed the server has only kept H2 and does not retain H1. If they had retained H1, then yes, they could has H0 and compare to H1, but they have kept H2.
If you think about it, while H1 is what you originally sent to the server, from the server perspective, it is just a password - a potentially long password, but just a password none the less. The server then needs to hash that password to store it (creating H2). We would also hope that the server has no record of H1. When you authenticate, you send H1 which the server hashes to get H2. For your scheme to work, the server would also need to keep H1, which would be like keeping a plain text password. Once a hacker got hold of the database of H1 hashes, they can access the server as the user associated with that hash without having to do anything else.
The other slightly glossed over part of your suggestiong which probably needs more thought is
Patch the client to now send (and the server to now require) the hash H0.
That is a potential problem or at the very least, likely to be as much work as just changing your password. If you were to allow this sort of pathing automatically and thereby reduce/avoid the need for the user to take action, your opening up another potential security problem - how/who would initiate that patching and how would you prevent unauthorised patching. If you want the user to do the patching, it will probably take more effort to get right than just getting them to change their password.
EDIT: As pointed out in the comment, you could verify the H0 hash by hashing it twice H0 -> H1 -> H2 and comparing with the H2 the server has. So perhaps that part of the equation might work.
However, the patching or coordination of the move from using H1 to using H0 is still problematic IMO. 'Normal' update/patch mechanisms will not work as such mechanisms rely on a single trust 'source of truth'. For example, if your on windows you trust the windows update service and if your on OSX you trust the OSX update service. But with respect to web sites, we are dealing with decentralised infrastructure.
Consider an environment where this scheme has been adopted by all or some subset of all the web servers out there. If a web server is compromised, then somehow it is necessary for that server to inform the client that they now need to send H0 rather than H1. At this point, things begin to get very complex and complexity is the natural enemy of security.
You can't make the change globally i.e now require all sites which use this scheme to use H0 instead of H1 because this would cause a coordination issue - you would somehow need to tell all servers which use the scheme to switch to the H0 -> H1 -> h2 method. Now you have to update servers and clients and coordinate that change or some sites would stop working.
Therefore, you would need to do this on a per site basis. This means you would need to have some mechanism built into your scheme which allows the server to tell the client which hash it wants for authentication - H0 or H1. Now you have another problem. How do you protect against a rogue server asking for H0?
Given that one of the biggest problems with any password scheme is that people tend to use the same password on multiple sites. We know this is bad practice, but people do it anyway. If you were to visit a bad server, it could ask for H0. Now that server has H0 and can hash it to get H1 and use that hash to access other servers you might use which are still relying on the original H1 as password. This could even be part of another attack vector on compromised hosts - once you have compromised a host, you could start asking for H0 hashes.
the real problem here is that we are adding additional complexity, which will add unforeseen 'holes' which only adds minimal possible additional security and fails to fix the fundamental (and probably unfixable) approach of using passwords to secure access - bottom line is passwords as an access control on their own is just fundamentally broken. What is really needed is a convenient way to add additional factors to the authentication process and move away from approaches which rely on a simple secret word