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 SriptSigs nulled out) and the PubKeyScript 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 PubKeyScript 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.