> But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.

This is meant to be solved by the cross-device flow - a QR code pops up that you scan, and a secure channel is established from that with your other device.

[Disclosure: an editor of said standard]

> The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for.

On macOS/iOS, the system gives this prompt regardless of where your passkeys are being created/stored:

Save a passkey?

"<site>" supports passkeys, a stronger alternative to passwords that cannot be leaked or stolen. A passkey for "<username>" will be saved in "<provider>".

There is a transparent upgrade option though that sites can request - basically when a site supports passwords and passkeys, they can request a password manager supporting both create and return a new passkey on password sign-in.

> [...] and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).

That's unfortunate. A site/service should absolutely not replace other passkeys, nor should it remove other sign-in options like passwords, without explicit user consent.

The above credential upgrade flow makes that doubly so; even if someone relies on a password manager to manage and provide their credentials for a site, it very well may not be the singular piece of software that does so.