If the actual domain name is used to generate the key that would also completely eliminates the ability to do phishing-attacks. Paypal.com and PaypaI.com would generate two completely different keys.
Why introduce such a risk when there’s no reason to do that?
In both cases your device has a private key that it needs to secure. In my scenario we remove the third party cloud service.
If I delete a credential, the expectation is that registering a new credential is not going to correlate the authenticator (and thus the user).
If I want to have hygiene steps of rotating the cryptographic key a user uses to log in, I won't want registration to create the same key pair each registration.
And for the cloud sync:
The UX can present that web authentication is an option to log in. The user will be confused if that option is presented for sites which will not recognize the authenticator.
The site can store data alongside a credential to be returned to optimize the log in process, such as a site-specified identifier to look up the user credential in a database. That state needs to be synchronized.
No cloud, no synching, nothing. You're fucked if your passphrase is stolen, but that's the tradeoff.
That’s part of the design though. That’s what completely eliminates the ability to do phishing-attacks.
If there were a common root to leak, that would just provide a new target for phishing attacks, and effectively risk reducing a persons entire online security down to 1 shared root-key.
While obviously better than having just 1 common shared password, why reintroduce this risk when you don’t have to?