That would be a breaking change in the specs for all the hardware signers that implemented it.
I think adding the /T step (whether hardened or unhardened) for each of the involved keys (rather than modifying the descriptor template) achieves the same without breaking changes, so your descriptor above would still be just tr(musig(@0,@1)/**,{and_v(v:pk(@0/**),older(12960))}, but each key has the additional derivation step for the xpubs (so /T only appears in the key origins, rather than in the descriptor template).
In that form, the fact that T is the same for all keys is not a requirement - and I don’t think it’s practical to expect it in a multiparty setting: people will provide an xpub at a different time. Forcing it to match would require a round of communication prior to exporting the xpub. While I expect wallets to just store the other parties’ key origins if they have it, that is not always possible and wallets should probably avoid relying on its knowledge at all.