I think we might want to be a bit more explicit about which attributes should be in scope for this feature.

l think I understand the reasoning behind wanting all attributes [1] to be in scope: I imagine it would be easier to explain that this is simply how ID/reference attributes work, in general. Also, adding an existing attribute into the scope of attributes which support referenceTarget after the feature ships would be a breaking change.

However, there are at least two attributes which seem to me to be potentially out of scope, and I don't see any WPT tests for them:

headers on <td>/<tr> (listed in the explainer as being in-scope)
itemref - a global attribute used in Microdata (not listed in the explainer)

If we did exclude those attributes, we would need to consider how to:

explain to developers why some attributes don't follow referenceTarget forwarding
consider how any future attributes should opt in or out of referenceTarget behaviour.

[1] The explainer states:

This feature is intended to work with all attributes that refer to another element by ID string. These are:

ARIA

aria-activedescendant

aria-controls

aria-describedby

aria-details

aria-errormessage

aria-flowto

aria-labelledby

aria-owns

Inputs

for (also supports the click behavior of labels)

form

list

popovertarget

anchor (proposed in the Popover API Explainer)

commandfor (proposed in Invokers Explainer)

interesttarget (proposed in Invokers Explainer)

Tables

headers