Should the wcagLevelRegexes be terminated by ^ and $ to avoid, say, matching wcag2aaa by accident?

Yes it should :) Fixed

It's non-obvious that findTagIssues relies on the WCAG entry being first in the list, maybe leave a comment noting that that's important?

The only thing left in the array at this point is misc tags or unknown tags, so stating order seems irrelevant as the unknown tags will be flagged for removal.

This checks misc tags are in the correct order. The issue message can be better here though. I'll change that.

Should we enforce that the order of tags follows this array? Right now it doesn't matter if section508 comes before EN-9, but does that matter?

It does a little, yes. The order in which we list tags in the rule is the order in which they show up in other places. Having a consistent order will make it a little easier for people to find the tag they are looking for. It's minor, but it helps I think.

The . separators here feel a bit inconsistent with other tags as a separator for what are spaces in the official standard being referenced. Other existing cases either omit a separator (Section 508 -> section508) or use a hyphen (best-bractice). I think EN-301-549 is the nicest-looking consistent option, but I think any of EN301549, en301549, en-301-549 would be fine.

This feedback is minor; I don't think creates big backcompat issues, so if anyone else felt strongly about the .s, I can live with the inconsistency.

Dashes make sense. @straker what do you think of EN-301-549?

I'm good with dashes

Using just EN without any other prefix makes me nervous about creating future backcompat issues; I think future revisions of EN 301 549 are likely to maintain consistent section numbering, but if there's ever a future different EN standard to, say, cover WCAG 3, it's reasonably likely it'd use conflicting numbering. That leads me to prefer using a fuller prefix here, like EN-301-549-9.1.2.3 or EN-301-549.9.1.2.3.

We have that problem with other tags too. wcag111 won't be relevant when WCAG 3 comes out. TT1.a will probably be obsolete when Trusted Tester v6 comes out. Don't quite know what we're going to do at that point but it seems likely we need to come up with something different by that time.

I can well imagine we deprecate the criteria/section specific tags all together and put that information somewhere else. That's what we did with the ACT Rules, we added an actId prop to the rule.

As discussed, the plan is to eventually not include SC numbers / section numbers into tags but make them available in some other format in the output. For now we're going with what we've been doing up until this point.