The latest version of the browser extension (2024.1.0) reverts the prior implementation of PR #6787 (released in 2023.10.2), which suppressed Bitwarden’s passkey prompt (automatically falling back to the native “use browser” option) when no passkeys exist in Bitwarden for a given website.
The justification for reverting #7678 that is given in PR #7135 is:
In #6787, we added logic to bypass the Bitwarden passkey prompt when no passkeys are found for the given site.
However, we have uncovered a security vulnerability in this implementation, as it leaks to the RP whether or not the credential exists.
Can someone explain the “security vulnerability” associated with letting the Relying Party (“RP”) know whether or not the Bitwarden vault contains a passkey for the domain? The RP is the website or online service to which you are authenticating (by username/password and/or by FIDO2 passkey). Why would it matter if they find out that we have or don’t have a passkey for the RP domain stored in our vault?
I am concerned that reverting PR #6787 will bring back a lot of undesirable behavior that marred the initial roll-out of passkey support.
I understand that it will be possible to add domains to the Excluded Domains list to suppress Bitwarden involvement on the sites enumerated there, but that seems like it will devolve into a never-ending game of whack-a-mole 
, adding domains little by little to an ever-growing list, which may eventually comprise thousands of entries. Such a list will quickly become unwieldy, making it difficult to manage and most likely adding unnecessary delays to the login process.
In contrast, with the #6768 implementation, it was sufficient for the Excluded Domains list to contain a handful of special cases (i.e., websites where FIDO2 credentials need to be supplied while the Bitwarden extension is locked).
Getting a clear explanation of the security vulnerability that prompted PR #7135 would be helpful. If, as I suspect, the vulnerability does not actually create a major risk (i.e., nothing worse than enabling auto-fill on page load, or setting a vault timeout of Never, etc.), then I would make the case for allowing the user to have an option to retain the old (#6768) behavior.