This was read herring. The same error also happens when session does not crash (although it would still be good if lightdm provided the proper seat).
Educated guess is that the second xfce4-session receives the same session D-Bus address as the already running Xfce session, so it got confused by “incorrect” responses (e.g. a lot of programs started as part of normal session are already registered even though the second xfce4-session did not yet even attempt to start them). As proof of concept, launching second session in separate D-Bis environment works:
bor@localhost:~> diff -up /etc/xdg/xfce4/xinitrc .config/xfce4/xinitrc
--- /etc/xdg/xfce4/xinitrc 2022-05-12 04:30:49.000000000 +0300
+++ .config/xfce4/xinitrc 2022-08-03 16:39:15.315315416 +0300
@@ -90,7 +90,7 @@ EOF
fi
else
# start xfce4-session normally
- exec xfce4-session
+ exec dbus-launch xfce4-session
fi
# if we got here, then exec failed
bor@localhost:~>
This is general direction today - there can be only one graphical session which is using session D-Bus and systemd user instance. Attempt to start second session always has mixed results (e.g. it may appear to be started but launched programs are shown on display associated with the session started first).
I am afraid it is simply not supported. Of course one may wish better error handling (like error popup telling user that session is already started), but that again is something to report/request upstream.