* There's no serious set of test cases. Many Bcrypt implementations were bitten recently when it turned out that they didn't properly handle characters with the high bit set.
* It only ever uses a work factor exponent of 8 which is probably too small for most modern use.
* Even if the password hash specifies a different work factor it will still use 8, and then fail.
* It's not going to interoperate with other implementations for these two reasons.
* The timing of regex's excecution probably leaks information about the salt.
* It uses perl's 'eq' for comparing the strings. The time that this function takes to run is probably dependent on the length of the matching prefix of the two strings. So there's possibly a timing attack enabling an unauthenticated remote attacker to read some of the password hash string. He may need to know the salt, but the salt is not considered a strongly-kept secret. Nate Lawson's blog is a great source on this topic http://rdist.root.org/2010/01/