Interesting. I believe to recognize some of this conversation from the forum, but do not think I ever saw the related MSGH issues before.
Swiping, and the exact presentation format of the inbox, are fairly independent of how to handle episode states. With that said, I do not have many opinions on them. I do however wish for changes in state handling which would appear as improvements for every reasonable usage scenario.
Currently each episode has one out of three states which is technically stored in the field read in the FeedItems table of the database. This state can take the values: unplayed 0, played 1 and new -1.
It seems like the inbox post and #5267 suggests adding a fourth queued/will-possibly-listen and fifth ignored state there, alternatively another boolean field to model essentially the same thing. It is not clear to me what value these suggested new states would add, or how more complex state transitions would make app easier to use.
Reading through #5237 gives me the impression that not everyone are completely sold on the idea of an ignored state (regardless of name), and my opinion is that it seems to be a request to add unneeded complexity which could better be solved by improving how the states are presented and manipulated.
Wouldn’t my three suggestions be (the main part of) a much simpler solution, providing the exact same value to users? Three states is all that is needed to represent fresh, will-possibly-listen and wont-listen. Is there really a use case where it would be meaningfully interesting to separate will-possibly-listen into shall-listen and undecided as suggested? Isn’t such separation exactly what the actual queue is used for? What is the desired goal with adding an ignored state in the more complex way suggested?
One would of course need to redesign the auto-download feature, but that is a fact for all changes related to state handling.