I have a comment about the 'input_index' of the transaction digest for taproot signatures. It is currently listed as 2 bytes. I think it would be better to expand that to 4 bytes.
The two byte limit is derived from the block size / weight limit, which limits the maximum size of a transaction, which in turn, due to a minimum size of an inputs, places a limit on the maximum number of inputs.
However, I think it is a mistake to mix limits from the block layer into the transaction layer of the consensus rules. For example, I believe that, as it stands currently, if we wanted to hardfork an increase in the block weight limit, doing so wouldn't have any impact on the transaction layer and we could transparently manage larger transactions with the current transaction format [2]. However if we start incorporating the block limits into the transaction layer, then we run the risk of such a hard fork needing to also make consensus changes in the transaction format/interpretation if we wanted to handle larger transaction sizes, which, while doable, wouldn't be so great.
The current transaction format limits the number of inputs (and the number of outputs) to 2^32-1 or less [1]. So using 4 bytes for the 'input_index' will suffice.
Given that adding 2 bytes to the signed transaction digest isn't a big
deal, it's probably better just to keep block limits and transaction limits
separate.
[1]The var-integer field for the number of inputs (and the number of outputs) in a transaction looks like it should allow upto 2^64-1 inputs; however this is an illusion. The P2P rules dictate that these values are immediately taken modulo 2^32 after decoding. For example, if the number of inputs is a var-integer encoding of 0x0100000001, it is actually just a non-canonical way of encoding that there is 1 input. Try this at home!
[2]If we were to hardfork an increase in the block weight limit, we would probably want to still keep the limit on the size of transactions that consume legacy UTXOs in order to avoid the quadratic computation problems that plagues the legacy transaction digest.