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 You’ve probably already considered this, but maybe the presence of some kind of question mark icon or similar badge on episodes in cases where extras are being kept could inform people about why. Maybe if they realize there are seven episodes instead of five because the extra two are some weird special case, they won’t need to ask you for support.
@DavidAnson @marcoarment I think this is smart. I was looking through the comments for this idea or a similar one. One or more flags/state toggle icons on the episode could show whether the episode is in “Auto”, “pinned”, “in progress”, “whatever”…and only “auto” episodes would be collected. Secondary preference rules on how to handle those other states could be available globally or per-playlist, but they could just be left for manual cleanup by the user. This isn’t a good idea yet, but I think it could be iterated into a decent design.