GSettings only requires glib, so no reason to disable it shm only requires glibc (it's in sys/ because it may not on windows, etc), so I guess it should be in the main package also.
We don't do sys/ and ext/ stuff in main packages, no matter if they don't impose any extra deps. GSettings is not packaged as a separate split yet because nothing actually uses it. SHM is not packaged yet as I didn't know yet what with to test it and also what uses it. Does farstream use it now?
Anyhow, basically we need to discuss if we want to ever include any ext/ or sys/ packages in the main one, or not. Currently the unwritten rule appears to be "no". So first this needs to get revised IF that's a good idea, then we can think about gsettings and gio in main packages after validating the eclasses to work nicely with it, imho. shm has extra deps on certain posix facilities, not sure these all exist on the prefix arches like interix, solaris, etc (they do have keywords on -base at least). At least shm is something that to my best understanding needs manual interaction in the application using it, so it's easy to know to have an explicit dep on a split package of it
My understanding was always that the reason for the split packages was to not add extra deps and use flags to the main one. I never understood it to be related to the directory organization of the gst packages. If the requirements for the shm stuff are not present on a platform, it will just not be built. If an application were to require the shm plugin, the application should not be keyworded on that platform. I don't see how this would be helped by having a separate package for shm.
SHM plugin is now available in 1.6.2, gsettings is out because it is unported and cannot be built. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c894f220d8104aa2b318c9b6e92f83fd62649234
