What is the point of including the scriptCode of the input in the transaction digest of segwit?

Question

BIP143 specifies "a new transaction digest algorithm".

5. scriptCode of the input (serialized as scripts inside CTxOuts)

What problems could arise if the scriptCode of the input were not included in the digest?

Answer 1

What problems could arise if the scriptCode of the input were not included in the digest?

Almost certainly nothing.

The reason for doing this is a very intentional design choice to limit the number of changes SegWit makes. Given that it has script versioning, it would be easy to introduce different sighashing schemes later if desired, we had the option of only making intended changes, as opposed to redesigning it from scratch. The intentional changes to the sighash algorithm are:

• Use shared precomputed per-transaction hashes to avoid O(n^2)
• Commit to amounts spent

So the hash structure remains the same, and contains all the same data. The sighash flags still have the same effect. The only thing that changes in BIP143 is that some data is now organized under precomputed hashes, and the input amounts go into it. Everything else is the same, which includes a commitment to the scriptCode - even though there is no good reason for that anymore.

EDIT: Do see Russell O'Connor's answer below for a minor use case.

Answer 2

As noted in BIP 143, the CODESEPARATOR opcode operates by truncating the scriptCode value that is included in the digest. While rarely used, CODESEPARATOR does provide a method to create signatures that are bound to specific code paths taken by Script, even when the same pubkey key used for redeeming the UTXO.

If the scriptCode were removed from the digest then CODESEPARATOR wouldn't work, unless we added back in support for it in some other way.