Just realized my third point probably relies on a construct that doesn't exist, encumbering a musig partial signature with an adapter... but it still seems like sig_A2..AN could be pre-shared as sig'_A2..AN, and alice would send Bob k instead of sig_A2..sig_AN. *hand waves again* You math people figure it out ;-)
https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da ?
That was an interesting read. The single biggest limitation is probably the inability to "skip" part of the path. Otherwise you could repeat the same participants M times, to get arbitrary transfers (with an eye-watering (M * N)^2 efficiency lol).
I was also thinking a bit about spend efficiency, you can probably do better than tap-leaf-per-case (which wasn't explicitly stated, but sort of implied) by compressing multiple CSVs into one tap leaf.
And then finally, I wonder if the "vertical" portion of signature sharing could be compressed by pre-sharing them all, and having some adapter which is constant between them? (guy with only a vague, intuitive understanding of signature adapters)
Discussion
Oh that part is for sure a thing, i.e. using adaptors specifically in a musig setting (it works better that way because the adaptor owner is forced to use the pre agreed aggregated nonce). That's how adaptors are used here and in adaptor based atomic swaps etc. Unless maybe I misunderstood what you're saying.