My concern isn't either, although both are interesting discussions - 1 in particular is relevant but understandable, as this prevents you from pairing tokens so you can maintain an off-site backup you don't have to retrieve every time you make a new account.
The specific challenge here is around software webauthn for passwordless access (think using Safari to create an account on a site). In this scenario, the average user has no portable authenticator. They cannot move to a new browser - you install Chrome, but can't log in from Chrome, as only safari can do a passkey login.
Even if chrome supports an equivalent setup (their version of passkey over Google sync, for example), you can't enroll it - to enroll, you need to sign in using Safari. To enroll your new device (chrome), you need to use it. You can't get logged in on chrome to do this. The average user has no option. A tech savvy user could manually copy session cookies to steal their own session, perhaps, or use a hardware key as a "bridge".
In essence, if you sign up for something using a passkey, you won't be able to easily leave that ecosystem at all, without pretty advanced tech knowledge (using a dedicated hardware webauthn key, or stealing and porting session cookies).
My separate observation about a lack of support for hardware keys to be "paired" to support an off-site backup use-case is unrelated, but perhaps relevant for tech savvy users who want to better "own" their own identity, and link their webauthn keys together for backup use-cases. Otherwise you have to maintain a list or spreadsheet of every site you use - I have one, so I can ensure I enroll each token I have with each service!
The specific challenge here is around software webauthn for passwordless access (think using Safari to create an account on a site). In this scenario, the average user has no portable authenticator. They cannot move to a new browser - you install Chrome, but can't log in from Chrome, as only safari can do a passkey login.
Even if chrome supports an equivalent setup (their version of passkey over Google sync, for example), you can't enroll it - to enroll, you need to sign in using Safari. To enroll your new device (chrome), you need to use it. You can't get logged in on chrome to do this. The average user has no option. A tech savvy user could manually copy session cookies to steal their own session, perhaps, or use a hardware key as a "bridge".
In essence, if you sign up for something using a passkey, you won't be able to easily leave that ecosystem at all, without pretty advanced tech knowledge (using a dedicated hardware webauthn key, or stealing and porting session cookies).
My separate observation about a lack of support for hardware keys to be "paired" to support an off-site backup use-case is unrelated, but perhaps relevant for tech savvy users who want to better "own" their own identity, and link their webauthn keys together for backup use-cases. Otherwise you have to maintain a list or spreadsheet of every site you use - I have one, so I can ensure I enroll each token I have with each service!