Post History

> Key idea #2: filters can be defined, named, and reused, and we'll provide some built-in ones. "Unanswered questions" seems like one that would be popular, for example. And if you want to refine the built-in "unanswered questions" filter (for example), you can.
> 
> **You'll have access to all your defined filters in all categories and on all communities** -- so if you want to have that meta "exclude status-completed" filter, you only have to write it once. When you choose a filter for a category, it'll stay that way until you choose another (or clear it).

(my boldface changes above)

I'm not sure how that would really work out in practice. There are some cases, like your example of Meta categories' status-\* tags, where it would probably work out very nicely, but also what seems like a large number of cases where it could lead to confusion.

Specifically, what I have in mind here is filter selection interaction with different (or the same) tag sets.

As a slightly contrived, entirely hypothetical example, not matching any community currently on Codidact so as to try to avoid stepping on anyone's toes. Imagine that there were two Codidact communities that do not currently exist, namely *Aviation* and *Rail Transportation*. Both of those have a tag named `atc`. However, on the Aviation community, `atc` means [Air Traffic Control](https://en.wikipedia.org/wiki/Air_traffic_control), and on the Rail Transportation community, `atc` means [Automatic Train Control](https://en.wikipedia.org/wiki/Automatic_train_control).

**If I set up a filter such that it lets me see only questions tagged `atc` and use it on each of those respective communities, what do I see on each? What's reasonable to *expect* to see?** (I'm not sure I have any good answer to that latter, but consider that to the typical *user*, tags are their names with some attached properties allowing the selection of a subset of posts; the typical user won't be considering tag sets when setting up a filter.)