Re: salted duplicate check
In any case, you need to store each user's salt value in plaintext so that you can use it when the user logs in. From this point of view, it is irrelevant if it is the same database, or a separate one for the salts. So all the salt values are available if you want to check if the user's candidate password is already in use by someone else.
All true, but this is precisely what should be infeasible once you have a substantial number of password verifiers. The security value of rejecting a "too common" password - which is very small, if there's any at all - doesn't justify throwing a bunch of computational resources at hashing the candidate password with every salt in the database. That's a dumb use of resources to achieve a pointless objective.
Password-strength restrictions are already a sign of failure: it indicates that users aren't willing to comply with security mechanisms because they see those mechanisms as too expensive for the value they provide. So the user experience is broken or the user doesn't have a clear view of what's at risk (or the risk is perceived as an externality). You have either a user interaction model problem or an economic problem.
If you aren't able to address that issue in any way other than a password-strength restriction (ie you're admitting failure), there are much, much better checks to use than "gosh, a whole bunch of other people used that password".