Ok, I finally get it. It's not about any material change in the signature or the transaction, but rather, the transaction hash does not include the signature.

Maybe I am muddling it up again but just intuitively I guess that "transaction hash" should be... you know... of the transaction.

Why exactly did they decide that the size of the ... if I am understanding it correctly, signature data, should have some kind of size limit on it other than the 1mb virtual bytes rule?

The signature is what joins the out points and the in points of the transaction. It's illogical to derive a unique identifier for a transaction that is based also on the signature that authorises it. Because there is always, and MUST be a random value in the signature or you have this pesky preimage problem. In my current exact task on Indra I have got signed advertisment pieces that have to be signed to be trusted (by the identity key of the peer) and they always have to have a different 64 bit value in there to make sure there isn't a leak of the private key bits.

I seem to recall that someone found a bunch of old wallets that had been generated with buggy code that signed on identical hashes repeatedly, leaking the private keys and with HD keys and secp256k1 curves if you break a child key and you have the xpub you can get the original seed quite cheaply. The article didn't point that out but fortunately some actually knowledgable people in the subject of cryptography pointed deeper into the article where they basically say that they could do this because the cryptographic protocol of the wallet was not using different values in the signatures.

Ah, 20:20 hindsight eh? Well, let's hope we aren't in line for future to write code that loses people money eh?

Also, why is there no limit on witness data???????? wt actual f??