Still, a warning wouldn’t be a bad idea though. After all, I was of the impression that whether a contract is a “real” contract or a proxy pointing to another contract shouldn’t matter. Calling the proxy and non-proxy the same way should have the same results (assuming same state/address/etc), and the same for delegate calls. It’s quite counter-intuitive that delegate-calling a proxy suddenly makes the proxy act as a “different” proxy (e.g. affected by your own beacon storage slot).
This issue should also happen for proxies that work by storing a logical implementation address instead of a beacon.
Also interesting, although not strictly about this EIP: delegate-calling a diamond (EIP-2535) would also suffer from this (it’d look for selectors in the caller’s DiamondStorage instead of the diamond’s). The reason why I’m mentioning this is because although it’s a bit too cumbersome for the “simple” proxies in this EIP (1967), it’s not unthinkable to deploy proxies (with or without beacons) pointing at a diamond, where upgrading the diamond would also “upgrade” all proxies pointing at it.
EDIT: Mentioned the diamond issue on the discussion for EIP-2535. I imagine that any progress/remarks both here and there affect both EIPs.