Ordinary Security Keys can't be synchronised so to as to be interchangeable. A good U2F/ WebAuthn implementation lets you enroll several of them and use any each time you sign in. So yeah, separate tokens, any of them works.
It's pretty different from authenticator apps, it can be much more convenient (no trying to quickly type in six digit numbers) but it's kinda expensive for now.
Ordinary Security Keys only know how to do exactly one thing, prove that they're still the same Security Key that they were the last time. They can't even prove which one they are in particular (most can prove which model they are, because a bank or something might be like "Ooh, we like this technology but we insist you use Bank of America brand Keys..." but they don't even know like a "serial number" or anything). This is deliberate - it allows the strongest possible privacy guarantees while still delivering a useful security function. The Firefox implementation lets you pick "No" when sites ask which model it is - I always do, none of their bloody business, it's a Security Key, eat it.
When you "enroll" a Key the site gets back a "cookie" (not an HTTP cookie) that is only useful to identify that site to that Security Key; a Elliptic Curve public key; and a signature proving the Key knows the corresponding private key and was enrolling with this specific web site. The site puts those somewhere (presumably a database table) ready to use them when you log in subsequently.
When you need to log in, the site gets its list of all the keys you've enrolled and says "OK, here are the cookies for some keys you enrolled, prove you still have one". If you have one of these keys it can find its cookie among the set, and it knows the private key that goes with that cookie, so it can sign a new message saying "Hi, this is still me, signing in to $domain right $now" and the site verifies that with the public key.
In principle the Security Key could be keeping a big database of every site it has enrolled with and the cookies used versus private keys. In practice what it does is make a random new private key each time it enrolls, encrypt the private key and put the result in the cookie. Only it knows how to decrypt the cookie, so there's no danger from this approach.