Google supports passkeys for their accounts now!

I would be particularly interested to know what the phrase in parentheses here means:
"Passkeys for Google accounts are stored on any compatible hardware — such as iPhones running iOS 16 and Android devices running Android 9 — and can be shared to other devices from the OS using services like iCloud or password managers like Dashlane and 1Password (expected to arrive in “early 2023”)."

Thanks for the explanation, @XIII.

I was puzzled because to me, we are already past "early 2023."

I admit I don't understand how passkeys work if it comes to where are credentials are created and with what basis data, what machine is performing what action, and where the credentials are finally stored and used. This is a major issue, because I'd like to understand a security mechanism, if I'm supposed and asked to use it.

When I activated passkeys in my Google account, Google told me I have 3 Android devices that "has passkeys" (whatever "has passkeys" meant, I never used passkeys with them).
When I actually signed up with Google Chrome on my Windows machine with passkeys, I was asked to provide one of these devices, which I did.
Then Windows stored "something" securely on the Windows system, because I had to provide my Hello pin.
Now, whenever I log in to Google on my Windows machine with passkeys, I am asked to provide my Hello pin, and then I'm logged in fine. I don't have to provide my smartphone, so the smartphone was somehow used as token, but not as credential storage.

My questions are:
1. Why was my smartphone asked with signing up (what secret or secure stuff was asked from it), and why isn't it necessary to provide it afterwards? What is it what Windows stored securely if it comes to passkeys, so the smartphone isn't required any more?
2. Why isn't it possible that Windows itself can provide the secret data that was provided by the smartphone on sign-in? So the smartphone isn't required even for sign-in?
3. (and as bonus, if 1Password wants to answer): how will 1Password link into this process to provide passkeys on their own?

I tried to find this information on the web, but unfortunately this implemented process isn't described anywhere. Only abstract theoretical diagrams about webauthn and passkeys and authentication clients can be found, but not how this is actually implemented and working from a user perspective.

@Dave_1P Many thanks for your answer. The linked Google blog post explained it best for me. It's brand new, so it wasn't available earlier this year when I researched about passkeys. From the blog it's clear what happened when I signed in for the first time and was asked to provide my smartphone. I guess, if I had no smartphone, I would be asked for the regular full mfa authentication (password + 2nd factor) to authenticate, and with this state the first passkey could be created instead.

From this information it's also clear that passkeys are not device-specific, so they can be stored and cloud-synced by password managers just like passwords. So your task is to link into the OS (or browser?)-provided API and offer it passkeys storage and management.

It's also clear passkeys really are what I initially thought they were: site specific public/private key pair to authenticate, with a lot of formal protocol and implementation rules to ensure interoperability and the documented security.

The important thing is they don't have to be device-specific. If they can with hardware sticks, ok, but currently it's not my intention to use a hardware stick, because the cost (in money and inconvenience) is too high compared to the now proposed passkeys software solution. I guess because I'm not alone with that reasoning, passkeys were developed in the first place.

The other day I realized Microsoft accounts also do support passkeys. I remember the Microsoft announcement from a year ago with their passwordless account campaign, however at the time I wasn't able to use it, and I wasn't able to recognize it was passkeys they were offering here.
The function is hidden and in plain sight at the same time.
There was also much blah in the announcement and it didn't become clear if that function was upcoming or already available.

It's hidden, because it's behind the same function where you register a hardware token for authentication, and it's in plain sight because it is one of the many authentication choices offered. So if you don't have a hardware key, you probably don't even try that choice.

On a PC, when you register passkeys for your Microsoft account, you initiate the process as if you were registering a hardware token such as a Yubikey. However, at some stage your browser offers a variety of devices. You can choose to use a hardware key on your local machine, and additionally you can use a smartphone device (I don't know from where the browser had a list of my 2 Android devices, however they showed up). I failed one year ago to use one of these, however the Google blog post made it clear why: If you select one of your smartphones, a Bluetooth connection is established to verify physical proximity. This failed one year ago, because I probably had Bluetooth deactivated on the phone or on the PC - and there was no notice given to activate it. Now it worked fine. As far as I remember, it was the same process as with the Google account in the end.

If all this is obvious and easy for you, and you already did all of this, please tell me. It would be a sign I'm getting old and should work on renewing my creative and cognitive skills.