This is why I've said that if I were starting from scratch today, I'd NEVER offer an episode-limit feature.

It's not that it's hard to delete the oldest episode when a new one comes in. That's trivial.

The hard part is meeting people's expectations.

Because when people say "Just keep the latest X episodes", what they really MEAN is a list of exceptions and behaviors that may be different from that… but everyone wants *different* behavior, because it's complicated!
https://mastodon.social/@overcastfm/113176856728462429

For instance, when evaluating an episode past the limit for deletion:

- What if it's an old episode that I went back and added?
- What if I've partly listened to it?
- What if I partly listened, but never finished it? (How long ago? How much is left?)
- What if I'm currently listening to it?
- What if I'm listening to it, but on a device that hasn't been used in a while?
- What if it's downloaded to the Watch? (How recently has that watch been used for standalone playback?)

So many questions.

And if you try to be smart about it, you end up with conditions in which a podcast might retain more episodes than the set limit, and then the feature looks broken and you get confused customers and negative feedback.

"I set it to X episodes, and there's X+1! It doesn't work!”

@marcoarment I think the root issue is how semi-conflated “downloaded”, “unlistened”, “current” and “was never current” are. I totally understand the benefits of tying them all together to a single read/unread state but I think the issues that you’re getting are indicative that it’s a leaky abstraction.

To me, anyway, my history is what’s important - that should never automatically change. That’s precious, time that I’d have to spend with my poor memory figuring out where I’m up to everywhere. In contrast what’s downloaded is sort of an implementation detail that should automatically change based on my settings, my storage, as it downloads, etc.