Is it feasible for you to replace y with b? It is compatible with b

That what I did in a local variable before invoking the compare function but I consider this as a hack and I'd prefer having 2y supported natively by the library .

Encountered this myself matching against some passwords in a database that were generated by legacy PHP code I'm trying to replace. I was able to work around the lack of matching $2y$ prefixes by doing the following:

const user = /* fetch user from DB */
const hashPass = /^\$2y\$/.test(user.password) ? '$2a$' + user.password.slice(4) : user.password
const match = await bcrypt.compare(clearPass, hashPass)
if (match) { /* login */ }

But I'd rather just be able to pass the user.password value directly into bcrypt.compare. Is there any reason not to support $2x$ and $2y$ prefixes, other than personal preference? It's not like there's an RFC that mandates $2a$ and $2b$ only. Besides, some tools still generate $2y$ today. For example, following the instructions at https://unix.stackexchange.com/a/419855, I ran htpasswd -bnBC 10 "" password | tr -d ':\n' and got $2y$10$su3VmyX96cZhMy1Hswn3ZehHSiMa0qqwnS0BMTAlYFhOgVViP6R4O. The htpasswd tool I used came from version 2.4.48 of the apache2-utils package, so it's not like this is an ancient version.

Since there are tools today that generate $2y$ prefixes, doesn't it make sense to support them equally alongside $2a$ and $2b$ prefixes?

Ran into this issue today and after reading the native code it seems like this is more a implementation decision rather than a personal preference. At the salt header check

The reason why it didn't support $2x$ or $2y$ is probably have to do with a bug in crypt_blowfish module in used in a really old PHP version from 2011. The discussion around the bug suggest that replacing $2a$ with $2x$ and only let crypt_blowfish module use the $2y$ header. I think nobody else used $2x$ or $2y$ as a header for bcrypt.