That's hard to say upfront. Last time it was systemd-homed randomly blocking ssh access to remote systems where it was not even configured to be used, other than distro sticking its pam module to default pam config. What will be the killer future this time is yet to be seen.
My last systemd mystery was nohup, tmux, etc, not being able to leave a process running. "Working as designed", sure, but it took a while for me to suspect systemd was involved and figure it out.
Is there a document somewhere that shows what the systemd team thinks is a functional boundary? What things they don't plan on replacing?
Why a disabled feature that should just do nothing even if its pam module is loaded, infinitely loops on D-BUS access in its pam module?
Anyway, I reported it and it presumably got fixed. I wouldn't know, because systemd dev handling this didn't say a thing to me at all. Just closed the report after some seemingly not very related commits to what I saw in gdb.
I just dropped the pam module from config anyway, and I'm not willing to lose access to my cluster again just to try.
Not sure how distro fucked up in this case, when it's homed pam module going into infinite loop once in a while unpredictably blocking all processes that use pam naively, unless you mean that they fucked up by using systemd or pam at all.
Edit: lol, I read through systemd release notes and there's no mention of new huge systemd-homed pam module at all. But good I looked, they're moving pam config for systemd to /usr/lib/pam.d and systemd-home pam module is again enabled there. So I'll have to check again all my systems if it's really disabled after upgrade.