We can extend the .desktop file further if this makes it possible to
do useful things. However, if we are going to ask all distros to
change the way they start dbus-launch to support DISABLE_DBUS_LAUNCH,
then perhaps we should rethink how we start D-Bus. Perhaps starting
this at Xsession time isn't the right place? Perhaps we should
always start dbus-launch in the /usr/share/xsession/*.desktop files
as needed? Or perhaps it should be managed more directly by
gnome-session itself rather than needing the login program/process
to be aware of D-Bus?
While there are certainly other ways of doing it, having dbus-launch
be the parent process of the session, ssh-agent style, is a robust way
of doing things, and I don't see a big argument for changing that and
forcing everybody to adapt (especially since the dbus for the session
makes sense in simplified contexts where they may not be a chunk of
code like gnome-session that could substitute for dbus-launch.)
Similarly, while moving dbus-launch into the desktop file would work,
that would require adapting all session desktop files in every
distribution in a way that would break (through double dbus-launches)
if the Xsession and the session files got out of sync.
My proposal was meant to be surgical - to just address the problem of
the exceptional case where you didn't want the system D-BUS service -
rather than to try and redesign things.