Taproot is specified in [BIP341][1] which also includes much relevant information such as motivation and rationale. My answer will essentially just rephrase some of its highlights.

Key path spends and script path spends are two distinct ways of spending a Taproot output. In a key path spend the sender just provides a signature that's valid for the public key in the P2TR output and the transaction being signed. In a script path spend the sender needs to provide a script, a proof that the P2TR output commits to this script (called the *control block*) and the initial stack to the script in order to satisfy it (which will generally include at least one signature).

You can tell if an input is a key path spend or a script path spend by how many witness items there are in its witness stack. If there is exactly one element in the witness stack<sup>1</sup> it is a key path spend, otherwise it is a script path spend. See an example transaction that has two inputs, one of which is a key path spend and the other is a script path spend:

[37777defed8717c581b4c0509329550e344bdc14ac38f71fc050096887e535c8][2]

Key path spending should be used when possible as it's cheaper and doesn't reveal the existence of a possible script path. Only when the key path cannot be used (for example when agreement cannot be reached in a multiparty protocol) should the script path be used as a backup.

MuSig2 uses aggregated keys, which are indistinguishable from ordinary keys and can likewise be used in both key path and script path spending.

<hr/>

<sup>1</sup> If there are at least two witness items and the last one starts with 0x50, it is the optional annex and it's removed before checking whether the input is a key path or script path spend.


  [1]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
  [2]: https://mempool.space/tx/37777defed8717c581b4c0509329550e344bdc14ac38f71fc050096887e535c8