I believe you'll find very few LSM authors that want to be running with another LSM. The only one that I've seen talk about it was the TOMOYO guy. You'll also get most if not all LSM authors to state that loading and unloading security modules at runtime is a bad idea and can't be done safely. That said its not the LSM folks responsibility to create things that they don't want which would probably include features that they don't see as safe. You are more than welcome to code up a stackable LSM solution and try to solve all of the corner cases for it. Once you do and post it to the LSM list we can have a meaningful discussion as to whether it is a viable implementation. Until then don't expect it to happen as it seems most if not all of the LSM authors have their hands full and some don't agree that its even a good idea. If you look at the grsecurity's take on LSM they think it is an absolutely horrible idea which is rife for exploitation by malicious code (I agree with this as well). Someone gave an example of them being able to use a stackable LSM framework but I'm sure brad isn't going to use it even if its there. I'm pretty sure if you look at the grsecurity patches it removes LSM.
As a side note I'm pretty sure stackable LSMs are going to be an administrative nightmare. People have a hard time as it is telling where the errors are when an LSM is involved and you want to add several ones that can potentially fail out at some point in the chain. Plus once you start having to allocate data structures you need to worry about unwinding the stack of allocations on failure. What happens if your free conditions can fail? What happens when you get past two LSMs which allow something to be freed but the 3rd doesn't?
So once again I invite you to take part in creating the framework you're looking for.