Filters were originally designed as a generic data filtering feature - specifically, they were never meant to affect cardinality as you mention. Therefore, it absolutely made sense to not apply them in various cases. The intention was always that once you had a particular id, filters were no longer needed.

Discriminated multi-tenancy support was implemented using filters, which introduces a specific requirement that is at odds with that original intention and specifically might very well need to affect cardinality - it is conceivable/likely that the tenant-id is part of the real unique identification.

So we do need to allow some facility for users to apply filters in these find-by-id cases for sure. In my opinion this should be opt-in behavior - we should not break existing applications which have been using filters.

And then there is also a “granularity” aspects - i.e., is this a global setting versus an attribute on @Filter(Def)? Here, I am not sure. Outside of specific evidence, I would say it is best to start global (setting).