Even though the later part is just about sorting the partial keys, I included it for context. But the summary is in Tim Ruffing's first answer: MuSig is only going to sign all of the signatures, or none at all. There is no "backout" that the MuSig provides.
i.e. an open problem left open. Although as I mentioned above, garlonicon suggested I use Pedersen commitments along with Multi/MuSig. After reading about that, I am not so sure what the secret r-value should be that will, at the same time, be an invalid secret for an ECDSA or Schnorr-type transaction.
Just for clarification: why is it an open problem compared to OP_CHECKMULTISIG? Currently, with an unresponsive party / lost seed, the output is unspendable, as well, right.
What is the 'backout' in regular multisig transactions?
It's very similar to the one used in LN (which itself makes use of multisignatures):
Basically, we have the problem that N parties want to send a bunch of transactions in one, by combining their balances. N-of-N is required to prevent theft. However, this means that if one person disappears, everyone's funds are inaccessible. So we usually do 1-of-N for transaction consolidation instead, but in case somebody tries to broadcast an invalid state, a "collateral" (in LN this is your channel balance) whose private key is known to the other parties should be taken away from him and divided among themselves.
In LN N is usually 2, so the dividing issue does not arise, however it would be desirable to have secure and always-available aggregated tx broadcasting. In this regard, MuSig by itself won't help because it requires N signatures, whereas only 1 is desired.
I see; so my understanding issue was that I assumed MuSig to be applied as a (N out of N) multisig drop-in alternative (which has the same problem that someone may disappear), meanwhile what you describe sounds like a type of CoinJoin (sending multiple transactions at once)?