If they detect something that matches what they want, they may throw some intermediate 301's to pages that attempt to infect the user with something still ultimately redirecting to the "normal" page.
In my experience, this solves the sticky 301 issue and you should have no issues with cached 301s anymore.
Works perfect for these kind of investigations or if you made a mistake during site development.
(Fingerprint usage: have https://myfingerprint.example.com 301 to https://myfingerprint.example.com/unique_id_3b136c1cb, then embed https://myfingerprint.example.com in an iframe and see which request is made.)
I still never use 301s for that reason. Things may have changed, but I dare not try!
I use 301 for http:->https: redirects because (a) I doubt we're going back, (b) it prevents some cleartext leaks (like the Host header), and (c) it is slightly cheaper.
> we never figured out how to get the browser to re-learn the responses for those pages without drastic measures.
If you control the target URL it is easy, just redirect back. Seriously: The browser won't loop, it'll just fetch the content again and now not seeing a 301 will forget that nonsense ever happened. This is why 301 is usually a fine default for same-site redirects, or if the redirect target is encoded in the URL (such as in tracking URLs).
The big no-no is don't 301 to a URL you can't control unless you have the appropriate Cache-Control headers on the redirect.
Just uh... don't do this if you have a CDN infront of your site. We had an incident where Cloudfront cached the 301's in both directions