We have a concrete use-case for which this facility is required. We have a requirement to add arbitrary tags in arbitrary groups to products, and to be able to filter by those tags in the same way as you can filter our documents by more-structured attributes (e.g. price, discount, size, designer, etc). The semantics we want are to ignore the filter on property X when faceting property X.
With our known-in-advance fields this is easy: taking the example of designers we add an fq=
designer_id:## for filtering and add facet.field=
designer_id when looking for designer facets.
With these unknown-in-advance fields it is hard: what we had hoped to do was use facet.field=arbitrary_tag_* to generate the tag group facets and then if someone filters to group X=Y we'd add fq=
arbitrary_tag_X:Y for the filter and pass facet.field=
arbitrary_tag_X to get the facets. Of course in this case we would also want to pass facet.field=arbitrary_tag_* to get the facets over the other tags which means faceting arbitrary_tag_X twice, and creates a precedence problem.
We want, I think, facet.field=arbitrary_tag_* to work, but to be disregarded for any field it would otherwise match which is explicitly named as a facet.field
The other model we have considered is to combine every group and tag into a string like "group\u001Ftag", put them all into a field named tags and facet over that. But this means that we can't disregard the filters over group X when faceting group X while respecting them while faceting group Y etc without making multiple queries.