It's unclear to me how such a tag would be used, especially in contrast to T982.

The tag would be used for individual beta features. VE, compact personal bar, HHVM, hover cards, which don't messes still need their own project in all cases. The Beta Features project is used for the beta feature framework, not individual projects within the framework.

The idea makes sense. There is an interest in following beta features in general, the related projects have common characteristics while they are a beta feature, and the Wikimedia Foundation has a clear interest in promoting this area.

It will require a bit of maintenance (when a project joins/leaves Beta Features, the related tasks will need to have a consistent use of this tag), but this can be solved with Herald rules (assign the tag automatically to new tasks created for any beta features projects) and batch edits (remove the tag when a project is graduated).

I'm about to reply at T982. I don't think there will be a problem separating clearly the use of both projects.

If there are no objections, I will create this project tomorrow.

With a clear project description we can create this though it's not entirely clear to me who is going to tag tickets accordingly and consistently. If a triager (e.g. me?) is supposed to tag tickets accordingly there probably needs to be a link in the project description to an overview (wikipage?) of existing Beta Features (and that overview needs to be kept updated of course).

@Aklapper, like any tagging system it will only be as good as our ability to tag things well, triggers, POs and eng, will all have to do their part to keep things tagged properly. This is also where the strucutred links will come in handy, e.g. if I make a structured add a task link from the project page of Hovercards I can add the arguments Beta-Feature and Title:Hovercards in to make that part semi-automatic.