Conceptually there is a different filter for each class of events: function events, messages and collective operations. During analysis the event is recognized when the expression is matched.
The behavior of a filter is determined at the time of its creation. A filter continues filtering until it is changed, even when the thread groups or function groups that it references are changed. Events are treated as belonging to these groups based on the state of the groups at the time the filter was first created.
If several events are merged as described in the Level of Detail section, then the merged event is tagged if at least one of the singular events is tagged.
Therefore you can use tagging in particular together with the Qualitative Timeline Chart to find events matching a certain criterion. If a single event out of billions matches the criteria of the tag filter, you see a highlighted peak in the Qualitative Timeline Chart that indicates where to zoom into the trace.
If an event is suppressed by filtering then the effect is as if it were never written to the trace file. This is relatively easy to understand for messages and collective operations.
However, if a filter is designed in the way that it suppresses MPI and enables all other functions to pass, then after filtering the Event Timeline looks as if MPI was not called. It looks as if the thread was in the calling function instead of being in MPI. The same is true for the call tree and the call graph of the Function Profile.
What happens if there are functions A, B and C in the trace where A calls B and B calls C and you filter B out? It appears as if A had called C directly. This is quite different from choosing a function aggregation that does not cover B, because that shows the function group other (other fgroup) wherever B was shown before. Filtering and Aggregation are independent.