Building on rimu’s point about not running the feed query twice: for the community page specifically there’s a cheaper signal already available. The community response carries a cached post count, so a UI could compare that against what the listing actually returns over a time window and show a hint like “some posts here are hidden by your filters” without a second heavy query.

For the main feeds, even a non-counting version would help a lot: when a feed comes back short or empty, show a small line listing which filter types are currently active (“you have 3 instance blocks, language filter on, hide-read on”) with a link to each setting. That’s just user settings the client already has, no new API, and it answers most of the “why can’t I see X” support questions.

The main challenge is that we’d need to run the ‘get posts’ database query twice - once with no filters and once with the filters. These are big queries so they’re slow and hard to optimize. You really really don’t want to run them more than once per page load.

If you wanted a breakdown of which filter caused how many posts then you’d need to run one query per filter and compare it with the no-filter version to see the difference. So, about 6x. Impractical.

If all the filtering was done in the app logic (rather than on the DB server, using SQL) then it would be trivial to count up which filter did what, as the code looped through the posts. But I’m very sceptical about the performance potential of this, there’s a reason why we do as much filtering as possible on the DB… It’d be an interesting experiment to try.