It may be unfortunate but packages have to run commands on installation sometimes and for Linux packages these may be Linux commands requiring Linux compatibility. These are taken from the RPM that we repackage. Usually these commands generate some sort of cache, like the ld.so cache or the fontconfig cache, etc. In general we cannot guarantee that packages work correctly if these caches aren't there. So I prefer that we require or at least suggest that Linux compatibility be enabled before installing Linux packages. Now for the specific case of linux_base. It runs ldconfig and gio-querymodules. If ldconfig fails that's ok, because the run-time linker can still find libraries by searching the library path. If gio-querymodules fails that's fine at the moment, because we don't have any ports that install GIO modules, but it's not unthinkable that we might one day. Having a port of gvfs for instance would make it possible to access remote locations in GTK file dialogs. So for now it's fine if the commands fail, but we can't promise users it will stay that way.
What if linux_base installed an rc script, eg /usr/local/etc/rc.d/linux_base, which contains the commands above, conditional on linux_enable being set, and with DEPENDS: linux? You could also have a file created on installation and upgrade time somewhere under /compat/linux/var, that would be removed on the first run of that script.
If the commands fail on package installation then they should run when the user runs service linux start. That doesn't happen with a linux_base rc.d script does it? I guess it would work if linux_base (and other Linux packages) installed a script in a location that is then sourced by /etc/rc.d/linux.