Web Authentication is basically generating and proving ownership of a private key. You have some hardware/software that manages these keys - it will generate a key at registration time, and then prove ownership as part of authentication. The keys are tied to a web domain and the domain is also included on the challenge/response, which breaks active phishing attempts.
When you are using WebAuthn as a second factor with a hardware key, you are typically using non-resident keys. These are keys that aren't being stored by the authenticator, only by the relying party (in this case GitHub). A "handle" is given at registration, which must be re-supplied at authentication. This is actually how the U2F keys work - the handle has the only copy of the exported, encrypted keys or key material, so the authenticator can't understand a request for authentication without getting that handle.
So, in this case even though it is the same physical hardware authenticator, you have done two registrations, which have generated two separate generated key pair, each with a key handle. Those key handles are saved to different accounts. When I use the authenticator as a second factor, only key handles associated with that account are used for the authentication challenge.
There are wrinkles here because of the diverse ecosystem, of course.
Some software implementations (like Windows Hello) have no premium on storage, so they will still store second factor keys. These still need to behave as above, but Windows will technically know it has been used multiple times on the same site.
Also, when using Web Authentication for primary authentication, you use what is called a resident key. In this case, the key is saved in memory along with metadata on which site it was generated for. The challenge doesn't include handles, but is effectively asking "do you have anything perhaps for GitHub.com?".
In this case, some authenticators simply won't support multiple accounts. Others will, and the browser or operating system will take responsibility for selecting which key is shared, via native UI.
When you are using WebAuthn as a second factor with a hardware key, you are typically using non-resident keys. These are keys that aren't being stored by the authenticator, only by the relying party (in this case GitHub). A "handle" is given at registration, which must be re-supplied at authentication. This is actually how the U2F keys work - the handle has the only copy of the exported, encrypted keys or key material, so the authenticator can't understand a request for authentication without getting that handle.
So, in this case even though it is the same physical hardware authenticator, you have done two registrations, which have generated two separate generated key pair, each with a key handle. Those key handles are saved to different accounts. When I use the authenticator as a second factor, only key handles associated with that account are used for the authentication challenge.
There are wrinkles here because of the diverse ecosystem, of course.
Some software implementations (like Windows Hello) have no premium on storage, so they will still store second factor keys. These still need to behave as above, but Windows will technically know it has been used multiple times on the same site.
Also, when using Web Authentication for primary authentication, you use what is called a resident key. In this case, the key is saved in memory along with metadata on which site it was generated for. The challenge doesn't include handles, but is effectively asking "do you have anything perhaps for GitHub.com?".
In this case, some authenticators simply won't support multiple accounts. Others will, and the browser or operating system will take responsibility for selecting which key is shared, via native UI.