I think all they need to do is remove attestation from the spec, or at least put very strong language around it that it should only be used for extremely secure environments where the data is not considered to be owned by the user, for example an account at your job. For end-user software, where they're currently promoting Passkeys, attestation is unacceptable. But, their behavior on the bug trackers indicates they don't even seem interested in having the conversation.
An open successor is basically impossible at this point. Years and years.
What can happen is that the open source and "noncompliant" passkey implementations spread to the point that it becomes impractical to block them, or something that can only be deployed to internal security where an organization can control their authentication mechanisms tightly because they provide the authentication tokens to their employees, and regardless of what the spec writers think or want, the de facto spec simply diverges from the de jure spec. It's not like that hasn't happened to basically every spec ever.
The good news is, I think the market is going to pushed pretty heavily in this direction for a long time. Bitwarden right now provides pretty much exactly the experience I am looking for from passkeys; I auth with my tool, and as long as I am authed, it provides the passkey. It already has mechanisms for not staying logged in indefinitely and requiring periodic refreshes, and I think passkey mechanisms that involve people basically still having to authenticate every time are going to be systematically disfavored in the market to ones that don't. Passkeys are a legitimate advance if I can do one log in in the browser or my password manager and be logged in to all my sites without further intervention; they're actually a downgrade if I now have to go through the effort of setting up a passkey and also still authenticating every time I want to use one. Whether or not it is abstractly a good idea, you can't just spec your way to something like this in practice.