Have you seen any case here where that would happen? The default 75 item limit should be large enough that this practically never occurs.

The cache is required because new releases can flood the RSS feed during the delay, potentially pushing the best release out of the feed’s size limit before the delay ends.

Thanks for the explanation!
I don't quite get it though - if it's checking for "better" versions, it needs to make another query. And if it's making another query, it'll know if something has been deleted. So I don't understand why it needs to cache anything.

The NZBs are keyed by ID, so can't really be renamed easily. It's a possibility, though I don't look too fondly over such a change.

Sonarr and Radarr have "Delay Profiles." This feature makes them wait for a set time (e.g., 60 minutes) after finding a matching release before starting the download. The idea is to allow time for potentially better quality versions to be uploaded. During this period, download links to suitable releases are cached.

Invalidating the original download URL upon deletion (perhaps by renaming the target file like some-release.nzb.gz to some-release.nzb.gz.deleted) is an equally effective solution without requiring the removal of the NZB files.