> How is it higher entropy? What's stopping a password from having 128 or 256 bits of entropy in it?

Admittedly, using "entropy" as the word here is bordering on an analogy break. "A picture is worth a thousand words": "a private key is worth a thousand characters of a password". It greatly increases the information complexity needed to just "brute force guess", as a rough off hand we call that "entropy" but what a Password Manager shows for estimated "password entropy" isn't a directly comparable "metric" to private key entropy (other than assuming that a private key is an order of magnitude "jump").

> If the website is compromised it doesn't matter either way since that password is not shared with any other site.

It still matters to using that specific site. If a website is breached and they get your password to that site, they can immediately use your password on that site. The potential damage is limited in theory to just the one site (and only limited in theory, not in practice, because in practice many social engineering attacks start with just a single site breach and spread), but the potential damage is still real. Whereas if they get a public key a website is using for authentication they might be able to encrypt some nastygrams that only your private key can read, but they can't actually authenticate anywhere with just a public key, not even the site they stole the public key from.

> And the UX doesn't seem to be the same at all. For one, according to comments in this very thread, Google and Apple aren't making these portable or user-backupable.

There's a lot of different definitions flying around for what constitutes "portable" and "user-backupable". There's also a lot of promised interoperability tools that haven't yet materialized and will answer some of these questions.

In terms of "average user UX" though, it is very comparable: on Apple devices if you use iCloud Keychain as your password manager, Apple's passkey implementation syncs the exact same (E2E) way and is not much different from "browser generated" passwords in Safari today. (Google's is similar but swap Apple names for things and E2E is "optional" for some dumb reason. Microsoft's is similar but swap OneDrive for iCloud and use more interop with iOS and Android phones.)

> Unless I'm grossly misunderstanding, that's not possible with passkeys, or at least not in the Google and Apple implementations? I would have to generate a new passkey on the new device, then enroll it with the website, and I would have to do that separately for each individual website/account? Not to mention, both devices have to be online at the same time? That's completely unworkable.

It sounds like you misunderstand how passkeys work. In general in the Apple implementation (which I have slightly more direct experience with) passkeys are built and stored like passwords in the iCloud Keychain. They sync with E2E-encrypted keys that are device-specific, but you enroll an Apple device once while two devices are online together (unless you have a much more desperate and harder recovery scenario) and once enrolled both devices have full offline access to all synchronized passkeys in exactly the same way they have access to all synchronized passwords in the same "Password Manager". (Think of it as a hierarchy with a few device-specific keys as the foundation being used to transfer lots more non-device-specific, but less powerful and website-specific keys to be used as passkeys.)

There are small exceptions that do make this easy to misunderstand/confuse: if a website "needs" an attestation similar to previous 2FA it may need something signed by a device-specific key in some situations. That should be much more rare in practice than the more password-like sort of passkey. That's also where more of the key operations want both devices online and talking via Bluetooth LTE personal area network. It's a 2FA operation trying to test that you have current access to a specific device. It shouldn't be something used for 95% of logins in the future once Passkeys are more stable.

(It is used a bunch right now for bootstrapping synchronization tools and cross-platform needs. Using iOS keys on Windows, for instance. Some of that is just waiting on some of the cross-provider interop features planned but not yet ready. Microsoft's efforts which are still somewhat behind Apple and Google are expected to be very much the "glue provider" as they will absolutely need to support both Apple and Google interop in Windows.)