It seems we all agree that libgnome/ui in their current form should be removed ASAP. But it seems people forget that we’ll still need a place for putting desktop policy APIs, and that makes libgnome/ui useful again. That is, instead of having lots of small libraries (gnome-menus, gnome-desktop, libpanel-applet, etc), it would make sense to me to have all those, desktop-related things, in one library that people use when they want their applications integrated into the GNOME desktop. Call it libgnome/ui or whatever, but you get the idea.
To start with, I’d mix gnome-menus and gnome-desktop, and then, if people agree, continue putting more stuff in those libraries. If done well, and only the right things are added, I think it would make sense a lot to have this GNOME Desktop integration library.
One level of separation I would like to see is between GTK and GNOME-specific libraries. This would make it a LOT easier to build lightweight, GTK-only versions of popular applications, simply by configuring out GNOME libraries at compilation time.
One example of where this would be useful is with Xubuntu’s evince-gtk. The amount of patching required to get Evince to build without GNOME stuff seems a bit ridiculous. This sort of diet version is exactly what’s expected for embeded devices and for GTK-based lightweight desktop environments.
Making it easier to scale DOWN applications, simply by skipping the all-in-one libgnomekitchensink you are talking about at configure time would be an extremely desirable feature. It would also simplify the life of those making embeded systems or assembling lightweight applications sets for desktop environmnets that don’t extend above the GTK layer.
We also need libgnome/ui for remote dialog authentication.
IMHO, yes, a library for desktop-related things would be nice but I would advise it NOT be the libgnome/ui. It could happen in another lib that would be renamed, once and only once current libgnome/ui had been killed. Clean, safer and with more visibility.