In T207609#4693508, @SQL wrote:

When I go to block an editor, I get a prompt about cookie blocks:

https://i.imgur.com/spgBe4c.png

When I go to block a range, I don't get the same options:

https://i.imgur.com/66XA0t6.png

The "includes cookie block" part was added on-wiki. Since T152462 (deployed this past May), IP blocks are affected as well as accounts. In both cases the cookie/autoblock expires after 24 hours.

There will of course be some collateral, but say this was a vandal using an open proxy, then the cookie correctly retains the block even after they stop using it. It's a trade-off, but either way it's not a bug. I'm guessing what happened here is you blocked some popular VPNs, and that's why you're seeing collateral.

I don't remember exactly, but the block message should say something like "you cannot edit because your IP address has autoblocked" (emphasis mine). It should also include the autoblock ID, which you can then look up at Special:BlockList. Maybe that's just for account-based autoblocks, though.

When we deployed account-based cookie blocks in 2017, we monitored the number of active autoblocks and didn't see a significant increase that would suggest it's causing widespread problems. IP-based cookie blocks in theory shouldn't be much worse, except maybe for shared devices. This was supposed to be a big win, as IPs are where see the most disruption -- especially for the drive-by vandal editing from residential IPv6 /64 ranges where the address can quickly change on its own. I have my doubts it's causing more harm than good, but I don't know if any formal analysis of collateral damage has been conducted for IP cookie blocks, specifically.

Given this is expected behaviour I think it's safe to close as invalid, but please re-open if I am wrong.