If you are storing the hashes of multiple passwords with the same salt, you are defeating the purpose of using a salt. The salt must be unique for each and every password, otherwise an attacker could compute H(password || salt) just once for each candidate password, and compare the resulting digest against every hash in your database, because they all use the same salt.
Also, as mentioned in the comments, you seem to be confusing the cost parameter for something else. The "10" specifies how much computation the bcrypt operation will take. A larger value increases the cost for attackers by making the operation more computationally expensive.
If you want to check for duplicate passwords, you don't need to come up with some homebrew scheme like this. If you really want, you can take the supplied password, concatenate it with the salt of the first user and hash it, and compare it against the stored hash. If it does not match, do the same for the second user, and so on. This does mean that each new password that is set will require walking through the entire database, but it will detect passwords that are exact duplicates.