I agree that, for most developers, salt from crypto/rand is the best choice and this bcrypt implemenation saves the developer from having to think about it. However, there are use-cases for externally provided salt so why not support it? All other KDF packages in x/crypto take salt as a parameter (pbkdf2, hkdf, scrypt). So does github.com/magical/argon2. Why not bcrypt too? Perhaps, for consistency with those packages the new function should be called Key(password, salt []byte, cost int)

@cruxic, @rhedile asked why you want this, and you didn't answer. You've said:

I find myself needing it now.

and

However, there are use-cases for externally provided salt so why not support it?

Again, why? What are the use cases?

If they are not particularly common, you always have the option of making a local copy of bcrypt.

Here are some use-cases:

1. [my actual use-case]
   I am experimenting with deterministic password generation. That is, generating website login passwords from a fixed seed (the salt in this case) and a "master password". The seed and password are given to to bcrypt() with a very high cost factor. This hash is then given to hmac_sha256(output_from_bcrypt, "somewebsite.com"). The output of the hmac is the basis of the final login password for somewebsite.com. The seed (salt) is persisted on the user's computer - the master password is not.

2. To save space in the database I don't store the salt, only the hash. Salt is computed as: sha256(mywebsitename + userID).

3. I'm going to encrypt a file with AES and a password. I generate the 16 byte IV using crypto/rand. I then wish to bcrypt the password using the IV as the salt. Using IV for the bcrypt salt reduces the file size by 16 bytes.

I do not consider myself an expert but know enough to hear alarm bells ringing. I personally feel you should review exactly how a "rainbow table" attack can be used to compromise the hash by attacking the salt to compromise the key. Please note that the Go implementation of bcrypt uses a fixed string for its IV. This is correct and acceptable. I am not convinced that using pseudorandom numbers as IV in block ciphers adds anything. I cannot speak for others, but I use Go bcrypt in Identity Management and judged the implementation competent and "safe" years ago. I would not like to be continually reviewing the code to monitor changes to an experimental API which could weaken the Package.
I cannot help but feeling that what you describe in your use cases is more like the blockchain cipher scrypt. Using that algorithm for Identity Management would be incorrect.

I am not convinced that using pseudorandom numbers as IV in block ciphers adds anything.

You may have misread my use-case 3? I suggested the IV be generated from crypto/rand, not a psuedo-random source.

Judging by the responses so far there seems to be no will to support this usage. My need is admittiedly a corner case. I will continue using my patched version of x/crypto/bcrypt.