Can confirm this. Additionally, the Bitwarden app on mobiles also checks the app name (i.e. the 'com.company.appname' not the 'user friendly' name). It takes an extra step to 'force' Bitwarden to use a username/password if the name/domain does not match the name/domain(s) recorded against the username/password which adds a nice bit of friction.
If I can't get my password thing to autofill on a mobile app (because the mobile app is on a different domain) then it's just annoying because I have to copy and paste over secrets.
That's the wrong thing twice over.
The password app should be as useful to me as a user as it can while still helping me be safe. "Hey, we can't confirm these creds are correct for this app. Do you still want to proceed?"
Silly question perhaps, but what happens if a certain website changes to a different domain. E.g. a takeover of Company B by Company A who then decides to migrate all Company B passkeys to Company A and removes assets hosted under the Company B domain. This is easily sorted with existing tools but with passkeys... how?
If they had time to prepare I'm sure they could develop a flow to get you a passkey on the new domain first. Similar to how YouTube used to do a bunch of cross-domain redirects (to plant cookies) to get Google+ login support back in the day.
You might not get a head up when you're forced to change your domain though. For example, recently a huge number of .ml domains are dead and people that used them must scramble to migrate to another domain. The problem is some apps like mastodon (and now passkey) don't support changing domains unless the old domain is still accessible.
It still wouldn't be a security problem, since WebAuthN includes the hash of the visited domain in the signature.
So even if Bitwarden would go blatantly out of spec and allow usage of a passkey created on and scoped to a.com on b.com, the assertion signature would effectively say "I want to login to b.com", which a.com would simply reject.
That's what makes it so much harder to phish than auto-filled passwords (which could still be MITMed e.g. through usage of attacker-installed TLS certificates).