gnome-keyring broken with dbus-x11 / multiple graphical sessions

Since b22d058a gnome-keyring-daemon does not work properly anymore with multiple graphical sessions using dbus-x11. In this setup, there is one dbus-session-bus per graphical session, meaning the gnome-keyring-control file cannot be shared between these sessions at the same file $XDG_RUNTIME_DIR/keyring/control. This regression was probably introduced some time before, but the above mentioned commit surfaced the breakage.

Before b22d058a:

When logging in to the second graphical session, libpam-gnome-keyring is unable to get XDG_RUNTIME_DIR from the process environment (only using getenv()) and thus fails lookup_daemon with GKD_CONTROL_RESULT_NO_DAEMON leading to https://gitlab.gnome.org/GNOME/gnome-keyring/-/blob/master/pam/gkr-pam-module.c#L945 being true and thus starting a new daemon for the new graphical session.

After b22d058a:

When logging in to the second graphical session, libpam-gnome-keyring gets XDG_RUNTIME_DIR from the pam environment (via get_any_env -> pam_getenv()) and unlocks the existing daemon from the existing graphical session. No new daemon is started. This also has the interesting behavior in the new session that each time something calls out to gnome-keyring via dbus, a dbus-activation is triggered, but runs into a similar issue, so no daemon is started on that session-bus and the dbus calls time out after ~30 seconds. This means any application action using the keyring is delayed by 30 seconds leading to a perceivably bad user experience.

Now, is it intentional that gnome-keyring does not support multiple graphical sessions / dbus-x11 anymore, or would you be open for a patch to make them compatible again? If yes, do you have a suggestion how this should work? I'd propose using a control file that not only depends on XDG_RUNTIME_DIR, but also XDG_SESSION_ID.