OP_CHECKSIG: reasoning behind construction of message to be signed I've closely studied the deservedly famous OP_CHECKSIG explanation found here, including the diagram found here. That explanation details how to construct the message that is signed via ECDSA, producing the digital signature for SigScript. All good.

By way of summary, the aforementioned message is an amalgamation of the new transaction under construction (with its ScriptSigs nulled out) and the scriptPubKey from the sourcing transaction output. For clarity, the "sourcing transaction output" is the one identified in the transaction input under construction by its Transaction Hash field and its Output Index field. All good.

MY QUESTION: in the new transaction under construction, its Transaction Hash field already "fingerprints" the sourcing transaction output. Why go to the effort of inserting the aforementioned scriptPubKey from the sourcing transaction output into the message? That seems redundant, given that the hash digest in the Transaction Hash field fingerprints the entire sourcing transaction.

I ask this question in order to more thoroughly understand the logic behind the intricate construction of the message that is signed via ECDSA.
I think, since with some sighash types, the scriptPubKey is not part of the txid. So it is not automatically taken into consideration when the txid is already part of the hash.