I'm still not quite sure, if it is good to have this v1 API and then more complicated v2, or could we have just one API.

Or whether this API should look a bit different so that adding v2 would feel a bit less weird.

Just as an example, not proposing this... what if this was more like
attribute ReferenceTarget referenceTarget;

and then
interface ReferenceTarget {
attribute DOMString? default;
// v2 would add more attributes
}

Where is the sketch for v2? We should at least have an idea on what this transition will look like. Did someone write that out?

Sorry for the slow follow up here -- v2 is sketched out at https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md#-phase-2-shadowroot-referencetargetmap-attribute.

That examples in that proposal imply an IDL like this:

interface ShadowRoot : DocumentFragment {
  // ...
  attribute DOMString? referenceTarget;
  attribute ReferenceTargetMap referenceTargetMap; // added in Phase 2.
}

// Added in Phase 2:
interface ReferenceTargetMap {
  DOMString? ariaControls;
  DOMString? ariaActiveDescendant;
  DOMString? htmlFor;
  // etc...
}

So the behavior would be that shadowRoot.referenceTarget is the default, and is overridden by any non-null values in the ReferenceTargetMap.

I can see an argument for grouping everything together into a single ReferenceTarget interface, but I do think it'd be nice to keep the simple case simple and allow a direct shadowRoot.referenceTarget = "target" rather than requiring the additional indirection shadowRoot.referenceTarget.default = "target". Either design seems basically reasonable though.

Where is the sketch for v2? We should at least have an idea on what this transition will look like. Did someone write that out?