Someone could get the cached of it, of course. But since it content addresses what it links to, it should avoid incoherent groups of cached data.
All in all it's a "certified hard problem", there's a bunch of domain specific nuance an HN thread couldn't hope to capture.
That said, I do find folks bend way too many things into fitting this pattern; such that I do not mean to be dismissive of the criticism.
As long as name client asks for (even if it is reference) is constant, it can have cache problems. Of course it makes it simpler as youc an opt to cache it so short that invalidation is less of an issue, but that's again working around cache invalidation
Or what if your CSS change just deletes some unused classes... it'd be fine for users to keep the old version until it expires. If you rename the resource you'll be causing a lot of users to wait unnecessarily. Not a huge problem, unless you're Meta or Google.
And so on.
When people say cache invalidation is hard it's best to believe them, because it is.
I think you missed the joke.
That's three things with an off-by-one error.
I think it’s open to interpretation. And I think it is valid to apply the saying to naming of variables, functions, and many other things.
See
https://skeptics.stackexchange.com/questions/19836/has-phil-...
Links to
https://www.karlton.org/2017/12/naming-things-hard/
Links to a bunch of places.
None of the ones I looked at seem to confidently say what was originally meant by the saying.
Either way, regardless of what the guy meant when he originally used to say it, it’s allowed to apply a saying to new situations.
Except that they‘re colliding all the time with that tiny problem that the world isn‘t pure... People expect the same page at the same URL, with different content, tomorrow, so good luck choosing a different one than the one they have bookmarked and that ranks on Google.
Caching doesn‘t get any less hard by trying to define the problem away.