No, it can't. MuSig itself cannot be k-of-n, but it can be used in applications that are k-of-n. Additional work must be done to make that happen, and it can and will be done where the participants in the multisig know who the others are and have proof that there are actually n people in the multisig, not some other number.

Again, you don't seem to understand what interactive and non-interactive means. It has nothing to do with "seeing the backroom players". All that interactive means is that the people in the multisig prove that they didn't make up some bullshit public key. Yes, they will see everyone involved. But you can still do that with a non-interactive scheme. Work is still being done on this topic to create a secure k-of-n scheme which avoids rogue key attacks (which is the class of attacks you are describing).

You seem to think that we don't know that k-of-n needs more work to make it secure. You seem to think that we don't know that the participants want proof of the other participants. Well, here's the thing, we're not stupid. All of the stuff that you thought of are things that we already thought of and are working on ways of solving. It's not like MuSig is immediately ready to be used for all Bitcoin multisig transactions and that was never claimed to be the case.

If you read the paper, you'll notice in the section on Applications to Bitcoin, k-of-n is briefly discussed. In it, various schemes are briefly proposed that would avoid rogue key attacks but still allow for non-interaction and secure-ness. Things like just not doing key aggregation at all for an actual multisig or using merkle trees to prove the existence of keys.

---

I'm done with arguing with someone who refuses to even understand the technology he is arguing about. Back to my ignore list you go.