Not many people are implementing passkeys yet, and we don’t want to force that on users. Also, the plugins we provide are still tightly integrated with the framework, you don’t even need to install a separate package, just import them.
If you want to make a case for tightly integrated plugins, then why aren't Passwords a plugin?
Also, there's a huge gap between "we don't want to force that on users" and "we don't advertise it in our top-level marketing site at all". I can't be the only HN reader that is evaluating all libraries like this for Passkey support. It took me four or five clicks to even realize this library even supported Passkeys at all. If I wasn't curious about other Plugins I probably would have dismissed this entire library as outdated for lacking even basic Passkey support.
Passkey is weird to recognize as a "brand", especially for mainstream users. It's more interesting to ask the average/mainstream user how many sites and apps they login to with their Face or their Fingerprint, and the numbers there are shifting rapidly and in interesting ways. You'll get a bunch of "false positives" that think any interaction with the iOS or Android built-in password managers count, but those "false positives" are also what is lifting the tide of larger Passkey adoption. The users comfortable with native password managers are also the users getting the easiest auto-enroll paths into using passkeys in supported places.
At this point the chicken and egg onus is on websites to support Passkeys, and to do it as a first-class and recommended experience, not on explaining to average users what a passkey "is" or arguing over how many they have. It is past time for auth frameworks and vendors to start steering people away from passwords (and towards passkeys, whether you want to "brand it" as passkeys or not).