I agree with your overall point that most of the big services do this correctly, but I do think we'll see more services that do this wrong as webauthn gains greater adoption. Developers are lazy and supporting multiple keys is more work than supporting a single key.
Just yesterday I discovered that Thinkst (Canary Tokens) only lets you register a single webauthn token. Thinkst is a company that makes security products! I'm expecting to see this more as adoption picks up.
I don't really understand the context in which "Thinkst only lets you register a single webauthn token". Poking around I see some free services (for which I don't need or want any credentials so WebAuthn is irrelevant) and marketing, presumably there's something else here but I don't know what it is.
As to the larger point, as well as explicitly telling you to support multiple tokens, WebAuthn is designed in a way that makes the "one single token" implementation pretty unergonomic, which you'd hope would cause anybody who isn't just copy-pasting to think "Huh, I wonder why I need a list of exactly one item here, and this other array with exactly one thing in it, and I have this database table with a column I never use for anything. What a strange design unless... oh right, yeah, we are explicitly required to support multiple tokens".
For example, the tokens have a mandatory ID for each enrolment. It's huge (larger than a UUID)! If you're never allowing multiple enrolments it might seem tempting to just forget the ID. There's only one per user, so it's not a problem right? Nope, now nothing works. Cryptographically this now can't work because the ID - while yes it's an identifier and you can totally use it as a PRIMARY KEY in your database or whatever - is also critical to the cryptographic underpinning and so if you've lost it now you can't do WebAuthn.
It is of course possible to get it wrong, not really any way around that, but I don't think it's often going to happen by mistake rather than policy.
> Poking around I see some free services (for which I don't need or want any credentials so WebAuthn is irrelevant) and marketing, presumably there's something else here but I don't know what it is.
To your larger point, I hope you are right. But I know I've worked with people in the past that given the task to add support to webauthn would (a) not bother to understand it more than the minimum copy paste examples from stack overflow or from a webauthn library and (b) would feel like adding a new SQL table to store store these would be "a lot more work" and "the jira ticket didn't say we needed to support more than one per user."
Just yesterday I discovered that Thinkst (Canary Tokens) only lets you register a single webauthn token. Thinkst is a company that makes security products! I'm expecting to see this more as adoption picks up.