Does taproot make sense for JM?

[freddiemacd]

Now that more taproot transactions are happening, if adopted in JM would it make transaction fees for coinjoins less by allowing participants to aggregate multiple input signatures together? It does happen that a maker may have 10+ inputs for a coinjoin, and if taproot would allow that maker to have 1 signature for all those inputs, it could be a significant saving. I don't know enough to know if that is possible but if it is, is there a plan to move in this direction?

[AdamISZ]

Taproot does not include cross-input-signature-aggregation.

CISA could offer savings in costs on transactions with a lot of inputs (though, a lot less than most people believe). But we have no active proposals in Bitcoin right now to implement it.

Taproot itself is not cheaper than native segwit, unfortunately. Its advantages lie elsewhere; it's cheaper for complex scripts, for big multisigs, it's more private, and it offers (via Schnorr) the ability to embed secrets into signatures (see: adaptors, PTLCs) which are very powerful. For vanilla coinjoins, these things are not relevant.