I think we both have exhausted our arguments regarding attestation. I understand why you don't want attestation to exist, and I believe you understand why I think it needed to exist in order for WebAuthn itself to exist. Like you, I hope it doesn't turn into a dystopia of every service requesting their own particular devices. So far, it doesn't look like it's going in that direction.

> I'd like to have that choice, yes. I don't think it would be good to act on that choice, but... Google should not be in charge of the device I use to submit a key

It's in Google's best interest to not damage their reputation with repeated break-ins to customer accounts and to reduce the overhead of an account recovery mechanism after an attack. It's the same rationale they use to not allow you to use "password" as a password, or why other services mandate 2FA. And again, Google isn't in control either, the authenticator is. Google (the RP) asks the browser (the client) for a user verification attribute. The authenticator is the one in charge of providing a response that sets that attribute. Without attestation, Google can't know if the authenticator did what it asked it to do.

> I have a solution that currently works (password vaults)

We're already seeing third-party sync fabric that don't use hardware elements without needing standard support. Dashlane already has it, 1Password is releasing it next month, and we're on a thread about initial support for it in KeePassXC. I'm sure soon after we'll see import capabilities for other password managers. Isn't this equivalent to the password manager you want to stick with?

All the extra discussion is around backing those sync fabrics with hardware (which is what I think will exist but outside of FIDO) and mandating implementors to allow exports (which I don't think will ever happen, nor do I personally want it or need it).