Unique constraint on hashed password database column

Question

This might be a stupid question and out of habit I wouldn't add a unique constraint to password hashes when stored in a database. However, I thought a bit about it and probably confused myself why this is considered a bad idea.

Assuming I use a secure hashing algorithm and a salt, then I would have a password stored in one column like alg.passwordhash.salt or in 3 columns like alg, passwordhash and salt. The password hash would be something like 512 bit long, the salt e.g. 128.

In the worst case every user chooses the exact same password. This limits the effective encryption strength to 128 from the random salt, because I could only generate 2^128 different hash values this way (even if each one would be 512 bits long). 128 bit is not as good as 512, but still good enough so that it is nearly impossible to run into collisions (UUIDs work that way and are 128 bit long). It would be similar to the generation and storage of session tokens that also must be unique.

I could now add a unique constraint to my passwords. If I use the 1-column design I would add it to this column, if I use the 3-column design I could even add one to the password hash and one to the salt.

There are two possible scenarios I see: An accidental collision and an intentional one.

An accidental violation of these unique constraints is very unlikely. Should it occur I could add a loop in my application to generate a new salt and re-hash the password until it can be stored in the database. It is virtually impossible to need more than 2 or 3 attempts.

An intentional violation would occur e.g. if some attacker manages to get access to the database (e.g. via SQL injection) and tries accessing other user accounts. Instead of reading and cracking all the hashes it would be much easier to overwrite the current password hashes of all accounts (or a few selected accounts to make it less obvious) to the hash and salt of their own account. Now the attacker can simply use their own password to login to the other account. A unique constraint would prevent setting multiple accounts to the same hash. The attacker could still change their own password again and use their previous hash and salt for any other account, but only for one at a time. So, the unique constraint can't prevent this attack but make it much slower and more cumbersome.

Summarized, to me it seems like the unique constraints would provide a bit (but not too much) more security with a bit (but not too much) of extra implementation effort, and it doesn't seem to be a no-go. Is there something I overlooked in my reasoning?