The rules governing this depend on the type of script used and whether that script is in the output script, in a P2SH, in a P2WSH, or in P2TR. Additionally, the rules are more restrictive for standardness than just validity.

`OP_CHECKMULTISIG` allows up to n=20. However there are other limitations due to script size limits that cause n to be smaller.

The alternate constructions of

```
<pubkey1> OP_CHECKSIG OP_SWAP <pubkey2> OP_CHECKSIG OP_ADD ... OP_SWAP <pubkeyn> OP_CHECKSIG OP_ADD <m> OP_NUMEQUALVERIFY
```

and 

```
<pubkey1> OP_CHECKSIG <pubkey2> OP_CHECKSIGADD ... <pubkeyn> OP_CHECKSIGADD <m> OP_NUMEQUAL
```
are only bounded by script size limits.

MuSig2 as specified in the draft BIP allows for up to n=2^32-1 keys. However if you do not follow the standard, it is effectively infinite.

***

Multisigs in output scripts can use either of the script constructions. In terms of standardness, only `OP_CHECKMULTISIG` with up to n=3 is allowed. However in terms of validity, `OP_CHECKMULTISIG` can be up to n=20. With the alternate construction, the limit is n=67. This is constrainged by the maximum number of non-push operations in the script of 201 operations.

In P2SH, the script is limited for validity by the stack element size limit of 520 bytes. This means n=15 using `OP_CHECKMULTISIG`. The alternate construction is limited to n=14. There are no standardness limits that would constrain this.

In P2WSH, the validity limits are the same as bare multisigs. It is limited to n=20 for `OP_CHECKMULTISIG` and n=67 with the alternate construction due to the operations limit. There are no standardness limits that would constrain this.

In P2TR, `OP_CHECKMULTISIG` is disabled, so only the `OP_CHECKSIGADD` construction can be used.  There are no standardness limits except for those that apply to the transaction as a whole. Additionally, the validity limits are those that apply to a block as a whole. With the maximum standard transaction weight of 400,000, a transaction could contain a script that uses `OP_CHECKSIGADD` that has n=11,759. With the maximum block weight of 4,000,000, n=117,637.

However with P2TR, MuSig is also possible. So those keys could each be a MuSig of 2^32-1 keys (or infinity keys if not using the draft BIP). Furthermore, it is possible to do nested MuSig (MuSig where keys are themselves MuSig), so this would also greatly expand the maximum number of keys that can be involved.