It gets worse. U2F keys were stateless, the site key pair was stored by the site (encrypted to, and by, the u2f key). Now, passkeys are stored in the device, and, you guessed it - they have a limited number of slots.
Not all passkeys need to be stored on the device. This is exactly what things like key-derivation functions are for. You can have a "primary" device key that derives a Passkey based on the site address with maybe a little salt and/or pepper (but maybe not needed with most KDFs).
FIDO2 allows that just fine, it's a complicated dance between the hardware vendor and the OS right now if your particular hardware device uses a full slot per Passkey or derives the Passkey from some "primary" key.
I have about 1000 accounts in my password manager. 100 passkeys to replace them is not enough. I wouldn't feel comfortable with that as a hard limit, if it's to replace all passwords.
Many of those 1000 are obsolete (old accounts I'll never use again), but many are not. At least 30 are things I use every week, most of them financial or tech admin, i.e. not social media. I'm confident (though not certain) that I login to more than 100 accounts over a typical year, and there are accounts that I sometimes login to more than a year since the previous time, glad that I recorded the credential.
If you don't get old stock - wasn't there some issue recently where they were still selling Yubikeys with the known vulnerability saying that "unless you knew about the vulnerability and specifically had a need to avoid it and told them", that that wasn't a problem?
Both are awkward in that I could reasonably expect to exceed them in the lifetime of a hardware authenticator.
The ideal number would be infinite and is in fact very achievable with a very small API modification, but alas, the WebAuthN working group didn't consider it necessary: https://github.com/w3c/webauthn/issues/1822
The fido2 situation is really bad.