Taproot is specified in BIP341 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. After removing the optional annex (the last witness item if it starts with 0x50), if there is exactly one element in the witness stack 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

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.

Taproot is specified in BIP341 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¹ 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

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.

¹ 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.