My impression was you wanted to stay as close as possible with current key/address handling and in particular wanted a map addr -> chaincode. The easiest multisig generalization (in terms of handling) would be one chaincode per multisig address. Matter of taste I guess.
Individual chaincodes per pubkey in a multisig can do potentially more, like combining different pubkeys from unrelated chains into a multisig. But that's far beyond scope of BIP 32 I assume. With one chaincode per address there is no handling issues and you can trivially implement derivation from a multisig address with very few additional lines of code.
Btw, it is my intention with Armory to do exactly what you just said is out of scope. There's no reason to optimize the case of multiple wallets coming from the same seed, because most of the time you don't ever want a single device seeing all the keys. You want your phone to create one key, your computer to create another key, completely independently. In the case of a big organization, you want different branches to create their wallets independently, and swap pubkey-chaincode pairs. They need to do that to guarantee that no one employee ever has access to all the pieces. And that all the pieces are never geographically co-located.
Plus, if there's, say, a vulnerability in one of the devices' RNG, you'd prefer that it only affect one piece of the multisig wallet.
There's a lot of possibilities there. While there may some use cases where keys are generated on the same device, that's far from guaranteed. In fact, I think it's the opposite, if we want to promote security best practices.