Why are path filters not evaluated for pushes to tags?

Having read this thread and path filters are not evaluated for pushes to tags in the documentation, I’m struggling to understand why path filters are not evaluated for pushes to tags.

We have a process where we run different workflows by creating tags and changing certain files. Lack of this feature forces us to either implement our own solution or use a different provider.

Is there a technical constraint that I’m not aware of to achieve this? I tried two-dot diffing a tag and a commit and was successful.

The path filter checks which files changed by pushing to a branch (between the commit before and after). A tag doesn’t have history, it only refers to a specific commit, so the question “which files changed by pushing this tag” doesn’t have a meaningful answer.

It doesn’t have to have a meaningful answer, I agree.

Nevertheless, why would this prevent us to have path filter evaluation for tags? Isn’t it still possible to execute git diff operation to a commit that a tag refers to?

It seems to me that it’s not possible to cover my case with the current version of GitHub Workflows.

That is possible. But the paths filter checks for changes compared to a previous version of the ref, and that only makes sense for branches.

When you push a tag there (usually) is no previous version of that tag to compare with. Redefining tags is technically possible, but generally a bad idea (see the git tag documentation section on re-tagging). So when you push a tag, the “previous version” is nothing, which means everything changed.