Some distributions compile SELinux into their kernels but have it disabled during boot while others compile both SELinux and AppArmor into their kernels and choose one, the other or none to enable on boot (since without LSM stacking, only one may be enabled at boot) and it is all of these systems where SELinux is not enabled that I was referring to. Specifically, these distributions could choose to compile AppArmor into their kernels (since without LSM stacking, both may be compiled in, but only one enabled) and let users/distro snapd packaging decide whether or not to adjust the kernel command line to turn on AppArmor at boot. IIRC, Arch does this today (@mborzecki, please correct me). Other distributions like Debian, SUSE and Ubuntu go one step further to compile both SELinux and AppArmor into the kernel and turn on AppArmor by default.
Fedora, RHEL and CentOS choose to compile SELinux into the kernel and enable it during boot. This would mean that if say Fedora started to compile AppArmor into the kernel, people would need to turn off SELinux and turn on AppArmor for strict mode snaps to work. LSM stacking makes this problem go away by allowing the distribution to choose its primary LSM, with secondary LSMs being ‘stacked’. In this manner, snapd the service on Fedora might be confined by SELinux (as it is today) but the application sandboxing policy snapd sets up would be for AppArmor. snapd/snap-confine would understand this and be able to launch snaps under enforcing AppArmor policy while the rest of the system is under SELinux restrictive mode. LSM stacking is also interesting because it allows container managers to launch containers with a different LSM (eg, think Ubuntu on RHEL or CentOS on Ubuntu) and for SELinux/SMACK systems to stack on themselves (ie, RHEL on RHEL with different host and container policies; AppArmor has allowed stacking on itself for quite some time, which is why today you can have strict mode snaps in LXD containers).
It is difficult to pin down. The feature has been in development for years (led by the SMACK LSM maintainer) with varying levels of interest depending on the year. It’s a massive feature that was broken up into many parts and many of the preliminary parts have already been upstreamed. AIUI, we are up to the 17th iteration of the patchset covering the remaining functionality. Currently there is renewed interest among the major LSMs and things are moving forward again. Ubuntu carries the LSM stacking patchset as a technology preview for people interested in trying it out.
Do note that AF_UNIX mediation in AppArmor does not strictly depend on LSM stacking landing, but many of the remaining questions wrt LSM stacking deal with the network stack which affects AF_UNIX. It is theoretically possible to land AF_UNIX ahead of LSM stacking, but we’d like to at least have many of the LSM stacking network questions answered (even if not committed) before submitting it since we would not want to redo the patchset later (or have it NAKd out of hand if it were deemed incompatible with a future LSM stacking feature).