While trying to deal with the problem in this thread:
which in the end used the * in the filter to address any field.
It took me a while and several failed attempts (with _ALL or _TAG) until I finally consulted the documentation.
Apparently, the filter behaves differently from other functions like "Case conversion" or "Remove field".
So my suggestion would be make the * as universal field place holder more public and add it to the field list that opens if you click on the right-arrow-button.
I would prefer it in the list of "extended tag fields" as it refers only to them, and perhaps a dividing line to the rest of the fields would make it stand out from the specifically named fields.
I prefer it as is, because the wildcard is supported for HAS and MATCHES only (and is documented for those) and, thus, adding it to the list of extended fields would suggest that it's generally available for all filter operators.
Support for format strings like %_path% and %_filename% is mentioned in the Notes section:
If <field> in HAS/IS/GREATER/LESS/EQUAL/MATCHES contains $ or % it should be enclosed in double quotation marks and will be treated as a format string instead of a tag field name.
Then 2 entries might save the idea:
instead of a single * * HAS * MATCHES
(... and these separated with a line in the list).
These 2 entries would insert exactly the expanded string with the * plus the filter keyword to start a correct expression.
I admit, I do see this as a clutch to save my initial idea. It is a break in concept to offer more than just a variable name.
The dilemma right now: have a more or less hidden but good function or risk a misuse a few times (which even now cannot be ruled out).
