My understanding is that we don't have real capability to do ((A and B) or C) yet (or at least, it's not standard), and that only M-of-N multisig is really enabled. I know you could execute any arbitrary script if you find a miner to do it for you, but that's not in scope for me -- I'm sticking with transactions that will be accepted by the network without special actions.
With what I had in mind, you wouldn't be restricted to any specific pattern of multisig transactions, the data structure could support any kind of multisig relationship imaginable. You would still restrict users' ability to create such relationships to the ones you consider in scope of course, but the file format itself would accept any.
Here is how I imagine a "relationship" data structure, let's do something weird: (A AND B) OR (C AND D AND E) OR (F AND A) OR ANY5OF (A,B,C,D,E,F), and C,D,E are the ones who can issue addresses.
Relationship
Number_Of_Parties = 6
I_Am_Party = A
Multisig_Script = OP_WHATEVER pubA OP_WHATEVER pubB OP_WHATEVER pubC etc...
Address_Issuing_Parties = C,D,E
Party
Position=A
Description=Captain
PrivateChain = xprvxxxxxx
PublicChain = xpubxxxxxx
Party
Position=B
Description=First Officer
PrivateChain = unknown
PublicChain = xpubxxxx
Party
Position=C
Description=Flight Attendant
PrivateChain = unknown
PublicChain = xpubxxxx
Party
Position=D
Description=Flight Attendant
PrivateChain = unknown
PublicChain = xpubxxxx
Party
Position=E
Description=Flight Attendant
PrivateChain = unknown
PublicChain = xpubxxxx
Party
Position=F
Description=Air Marshal
PrivateChain = unknown
PublicChain = xpubxxxx
This structure would originally be created by A, but with "unknowns" for the public keys for B,C,D,E,F, and serialized into a block of text. That block of text would be sent to the five other parties, who would recognize "OK, this is a multisig proposal with vacancies, which one should I join? First Officer, Flight Crew, or Air Marshal?". The clients of those parties would emit a record proposing to join the position they chose.
When all six parties have their own record, plus the five of the other parties, they should all recognize the group relationship and be able to start participating in it.
However, I agree that the design here should be extensible to these cases, when they become available in the future. But it also seems unnecessary to require extra user-interaction for regular M-of-N transactions where the specific ordering is actually irrelevant to the users, as long as it is deterministic and accessible to all participants. As a user entering a 2-of-3 wallet with two other parties, I don't actually care what order they go in, and asking the user to specify a totally arbitrary ordering is not only confusing, but ripe for people to do it wrong -- i.e. user A chooses {A,B,C}, but user B accidentally sets up their wallet with {B,A,C}, and then things get all out of whack...
At some point, one of the parties must take the initiative and decide "I'm creating a multisig wallet relationship, and the style will be 2-of-3". I am imagining the process similar to the CSR request for SSL certificates. At some point, when setting up SSL on a website, one party (web site operator) initiates the deal generating a CSR that says "I'm so-and-so, here is my public key, and I propose the creation of a certificate that looks like x". The other parties to the deal accept the proposal and respond with "Here is the certificate you asked for". Someone always has to go first, and there is nothing wrong with tying special responsibilities - like defining the proposed relationship - to the party who does.
At some point, all three parties must exchange some record so that they learn the public chain codes of the other parties. If they didn't do this, they would never be able to recognize incoming transactions belonging to the relationship. I see this step as unavoidable.
However, I do see a possibility that several of the roles could be equivalent. My example above has three "Flight Attendants". It could be defined that these positions are equivalent in purpose, and that which specific relationship member gets spot C, D, or E, is dictated by numerical order of a hash, rather than forcing the user to pick a spot deliberately hoping another member didn't pick the same one.
At some point, all three parties software must have the ability to express to the human user that they in fact all have the same parameters and keys in mind. I propose they do this by emitting a hash of the serialized relationship record containing all the public keys in the relationship. When the clients of all parties to the relationship say "Relationship Successfully Formed: Relationship ID F1175A23", the users can know that all parties are on the same page, and that (for example) party C didn't accidentally use a key that came from somewhere else.
Also, I don't see a reason why there should be a special case for desktop+second-factor (smartphone) vs shared-spouse-wallets. Just have all 2-of-2 wallets pretend that both chains could be used, because the resource usage of watching for a few extra addresses is trivial. If it's really a concern, there can be an option in "Expert" usermode to disable the second device chain if you know it won't be used.
I am not sure I understand how the resource usage is small. I understand a chain can be used to generate unlimited addresses. How should the software come to know that of all the addresses generated by party B (for example), the one with sequence number 10,000 has a transaction that needs to be checked for, even if all addresses 0 thru 9999 don't? I see no way other than actually generating all those addresses just in case and checking them all, and then there is no guarantee that 10000 or any other number is enough if you can't assume how the other party will be using addresses they generate. While such sparse utilization seems counterintuitive on the surface, it's not all that unusual if you consider that someone setting up an e-commerce web server might pre-generate a huge number of addresses assuming most will be wasted, and then give them out in an arbitrary order (e.g. alphabetical sort instead of the order in which they were actually generated). If my assumption that the only way for party A to truly know if party B has never received funds at addresses he has issue is to perform an operation that is unbounded in resource usage, it seems prudent to clip it from the start if the use case makes it clearly unlikely to be used. This of course discounts your assertion that "the resource usage of watching for a few addresses is trivial" - if I have overlooked something and this assertion is guaranteed to always be true for a reason I haven't considered, then yes I agree that it would be a waste to bother with an option that disables address generation roles for parties.