Why would any actor (user, client, or RP) really care if the same authenticator was registered twice at a site - once with a u2f credential and another with webauthn?

You could end up in a situation where your account security settings page has "duplicates" in the sense that they are two credentials on the same authenticator. I believe if both are present in allowCredentials the WebAuthn credential would probably override the U2F one, judging by how the appid extension client processing is written. So probably the U2F authenticator would end up not being used.

Here's a rather contrived scenario leading to a security issue:

1. Alice has been using authenticator A for a while, and has accidentally had it registered as both an AppID authenticator and an RP ID authenticator.
2. Mallory gifts Alice a next-generation authenticator B. Alice now wants to retire authenticator A and use authenticator B instead.
3. Alice registers authenticator B with an RP, then logs out and logs back in with authenticator A.
4. On the security settings page, Alice sees that "Authenticator A" was used to log in "less than a minute ago" and pushes the button to delete that authenticator from her account.
5. Confident that authenticator A can no longer be used to log in to her account, Alice gives authenticator A to Mallory.
6. Mallory, having planned this all along, can now use authenticator A to access Alice's account (assuming Mallory has also obtained Alice's password) since it's still registered as a U2F authenticator.

I think this problem, and many others, is probably best solved by teaching good security hygiene. We should encourage RPs to allow (or even require) users to set nicknames for their credentials, and to periodically encourage users to review their security settings and clean out any credentials that haven't been used in a while. I'm not sure it's appropriate to include such guidance in the spec, though. That might be better suited for third-party documentation.

In any case, at least there won't be any issues with orphaned resident credentials since U2F doesn't support them. As soon as they're deleted from the server, they're also "deleted" from the authenticator.

From an RP perspective: the user doesn't care much about, and probably doesn't even know, the difference between how their authenticator was registered. Ideally a migration is completely transparent to them and their U2F-registered credential should word just the same when the RP switches to WebAuthn (although some changes in browser UX may not be unavoidable, e.g. Chrome).

Double registration can be prevented in both U2F and WebAuthn, but in this migration scenario it breaks down and can cause confusion. It would be nice if this area was also fully backwards compatible/"just works".

I believe if both are present in allowCredentials the WebAuthn credential would probably override the U2F one, judging by how the appid extension client processing is written.

Based on some quick testing, Firefox 67 behaves this way. Chrome 74 seems to pick the first offered credential in allowCredentials, but this may be due to the AppID extension not working for me in Chrome and Safari.

but this may be due to the AppID extension not working for me in Chrome and Safari.

(If you have an issue in Chrome, please do file at crbug.com and point me at it. Something works with the appid extension in Chrome though because we moved accounts.google.com to it.)

While working on webauthn support for github.com, I was thoroughly confused by the existing behaviour and thought I did something wrong (e.g. perhaps I converted key handles to credential IDs in a way that works only for some cases).

Although @emlun's scenario is somewhat contrived, I would strongly like to echo the importance of a transparent migration from U2F. We don't want users to have think about which of their security key registrations are U2F vs. webauthn. It could be very confusing if a duplicate registration for the "same" key works only sometimes, especially given that it might work the "first" time but not the following times.

Or rather, it could be misleading instead of confusing. Experiences with debugging issues during our webauthn transition suggest that discrepancies like this can really mess with someone's mental model.

Also, I'd like to note that some major sites (e.g. google.com during initial launch) do not support naming registered authenticator keys, making it difficult to tell if a particular key is already registered/which registration it is.

So, we'd really like to see the webauthn support this behaviour!