What about just changing windows tags from fails to sth like failsOnWindows or so?
Having multiple locations is probably hard for auto adding tags and other stuff (although I thought to that idea first when adding slow tags as well).
About having an easier overview of what's left to fix, I think something to count the number of tagged examples (like wc -l) would be quite useful (and aggregating per directory), the file size being a bad indication. And in that case, filtering (grep) is not so much more work.

The windows tags are already fails(windows). It does indeed not work well with auto tagging - auto tag and untag will use the first path.

The main motivation for this was so that I can simply look at what works and what doesn't. A command to see that doesn't work as immediately.

But that means examples failing on Windows are also excluded on Unix, isn't it?
I meant to use another "Tag#tag", so maybe just windows instead of fail (slow being the third).

I think these are Windows specific tests - they aren't run unless you are on a Windows system.

FYI, I used two tags:

• (windows) -- Windows-specific spec
• (windows bug) -- General spec that happens to fail on Windows

And naturally, the "(windows bug)" specs may very well pass on your non-Windows install. Untagging them would end up causing a failure in Windows CI that you probably wouldn't see locally.

@nirvdrum Thanks, I thought it was sth like that but was not sure.
We could add an additional --excl-tag windowsBug on the Windows CI of course.

Should we close this issue then?
(Also I wish to have compatible MSpec and intend to propose my change (bug fix) to the canonical MSpec, but this one would be more debatable).

We decided the changes to MSpec weren't ideal and we'd like to keep all tags in one place.