Yes, see the recently published RFC9591 : "..However, unlike EdDSA, the signatures produced by FROST are not deterministic, since deriving nonces deterministically allows for a complete key-recovery attack in multi-party, discrete logarithm-based signatures."

The reason this very counter-intuitive footgun exists in MuSig2, FROST etc. : whereas typically you tie the *exact* nonce point R into the hash in standard Schnorr, i.e. you calculate s = k + H(R,..,message) where R is the point for k (R = kG), in the collaborative version (both FROST and Musig2) you do s = k + H(R_aggregated,..,message) where R_aggregated *includes* your individual R, but also adds in the other guys' R-values, too. So the attacker can make R_aggregated change for your s calculation, while your k value does *not* change if your private key and message don't change (you basically do k = H(privkey,message)). So you end up reusing the nonce on different equations and then the attacker can just subtract one of your s-values from the other. You signed a different "message" even though your actual message (e.g. the bitcoin transaction) was the same, because mathematically your "message" is "R, ..., message" and not just "message".

So you could see it as an impurity of the concept of 'nonce' leading to undesirable outcomes.

This is why MuSigDN and stuff like https://eprint.iacr.org/2021/1055 exist.