Rene Pickhardt brought up the problem of latency on the Lightning Network in this answer on using nested (or "recursive") MuSig2 or FROST when providing a signature within an existing Lightning channel or to cooperatively close a Lightning channel.
(This could be done once the Lightning protocol supports Schnorr signatures even if the 2-of-2 multisig between the channel counterparties that is funded at the opening of the channel remained 2-of-2.)
How to treat latency isn't spec'ed in the BOLTs. So how do the various Lightning implementations currently treat latency? How long do they wait for a peer to provide a signature before assuming the peer is unresponsive and instead using an unhappy path? This would give an upper limit on how long the MuSig2 or FROST protocol could (currently) take to generate a valid signature if they were used in this use case.