Introduction
BCrypt is a password-based KDF (far from state-of-the-art, but better than PBKDF2, because BCrypt requires sizable RAM, which greatly increases the cost of hardware-accelerated password search).
Bcrypt is based on the block cipher Blowfish, with the initial processing of the password reminiscent of Blowfish's key preprocessing. Bruce Schneier's Description of a new variable-length key, 64-bit block cipher (Blowfish) (in the proceedings of the first FSE conference, held Dec. 1993) defines that Blowfish's key is of 4 to 56 bytes (32 to 448 bits), with this rationale for the maximum:
The 448 limit on the key size ensures that the every bit of every subkey depends on every bit of the key. (Note that every bit of $P_{15}$, $P_{16}$, $P_{17}$, and $P_{18}$ does not affect every bit of the ciphertext, and that any S-box entry only has a $.06$ probability of affecting any single ciphertext block.)
Using more than 56 bytes of key for Blowfish is against its definition and design rationale: key bytes beyond the 72nd have no effect whatsoever, and the few before may have somewhat less diffusion (though not nearly as badly as the above quote suggests). Some Blowfish implementations nevertheless accept keys with any positive number of bytes.
Bcrypt, as defined in Niels Provos and David Mazières's A Future-Adaptable Password Scheme (in proceedings of Usenix 1999) accepts a key of 1 to 72 bytes; even with the lowest cost parameter, all key bytes have ample time to reach full diffusion. Bytes beyond the 72nd (if any) have no effect whatsoever. The mapping of password to key is "defined" by:
take user-chosen passwords as keys
and implementations are known to vary wildly. ASCII only? Some 8-bit codepage extension? Replacement of gremlins with 0x3F bytes? Little-endian or Big-endian UTF16 or UTF32? UTF8, with or without BOM? Length byte, zero-termination? Your guess!
What should be done if the password can be more than 72 bytes?
If there was a formal requirement that it is impossible to exhibit equivalent passwords, or that every character in a password is significant, or with UTF32-encoded passwords (thus only 18 characters), it would be bad to just truncate a password/passphrase to 72 bytes.
The option of replacing Bcrypt's mapping of password to key by a cryptographically secure hash is excellent, if all the characters in the password make it to the input of the hash, and all the bytes in the hash's output make it to the key (I can imagine an implementation where bytes beyond the leftmost 0x00 in the hash, if any, are just ignored; that would be extremely bad, for one in 256 passwords could be replaced by any password with the first byte of its hash equal to 0x00).
The hash should be computationally collision-resistant to a degree significantly better than the strength of the requirement that it is impossible to exhibit equivalent passwords (thus with output of $h$ bits with $h$ significantly above $2k$ if aiming at $k$-bit security level, and unbroken from a collision-resistance standpoint; no MD5, or even SHA-1 from a theoretical standpoint). The strength of all other properties (minimum expected cost for password search by brute force, first and second preimage resistance, resistance to length-extension, and more generally computational indistinguishibility from a random oracle) demonstrably follow from Bcrypt's security.
If there is an entropy of $e$ bits in the input password, and for a hash of $h$ bits indistinguishible from a random oracle, it is expected that there are about $\max(e,h)$ bits of entropy in the key fed to Bcrypt, nearly exactly when $e\ll h$ or $e\gg h$, and within less than about $0.83$ bits in the worst case $e=h$ (see this).
SHA-256 (32 bytes) is thus perfectly fine in practice for any password/passphrase that a human types in (or even more so, memorizes); SHA-512 (64 bytes) can't harm. Ample entropy remains if there was enough in the first place.