Document the adverse effects of isContract

It appears that Address.isContract is increasingly more popular as a 'safeguard' against flash loan attacks

I've seen this in other places too, but the most prominent one is Anyswap, which currently cannot work with smart wallets like Gnosis Safe, Argent, Ambire and other smart wallets because of this check

other than breaking smart wallets (where every user is a contract), general composability, it also doesn't protect from flash loans at all because you can just wrap the call in a create2 contract constructor, therefore getting isContract to return false (correct me if I'm wrong)

As such I've opened a PR here: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2994 to add more explicit docs regarding this danger

Agree on the assessment, trusting an address to be a contract or not in an adversarial setting is not secure. In addition, any future EIP like https://eips.ethereum.org/EIPS/eip-3074 would provide another way for bypassing these checks.

This approach is also insecure since, as you say, it completely breaks the protocol for any project that shoots for better security by working behind a multisig - thus forcing projects to move to an EOA, which is less secure.

Furthermore, if the goal is to protect against flash loan attacks, I'd argue that there's no such thing as a flash loan attack. There are flash loans, and there are protocols vulnerable to whales. The security of your project should not depend on no users having too much funds.

Completely agree with all of those points.