for account-associated encryption, what it should do instead is to generate a dedicated file encryption key for each backup, and encrypt said key with the account's passkeys. Each time the user adds a new passkey, it should save an additional copy of the backup's key encrypted with the new passkey. This way you can have multiple redundant passkeys that can decrypt the backup. This is basically how age's multi-recipient encryption works.
replyMost of these systems already do this, especially since very few applications have a flat encryption key hierarchy regardless of passkeys. The counterpoint would be that not everyone will set up multiple passkeys unless you require it on sign-up, but you're going to have that problem with any other method of storing end-to-end encryption keys. Might as well piggy-back on the password manager's replication methods.
replyYou're just saying that the user needs to be aware that you cannot forget or delete a password, which applies just the same way to passkeys.
replyPasskeys are effectively just long passwords you cannot see. The mechanism is just gravy.
I think there is a difference.
replySites usually have the user SEND their password to the site to authenticate. There is no need for sites to be written that way, but that is how they are written.
Passkeys cannot, by design, be sent to the site. Instead they use a challenge-response protocol.