Directives that instead of a reference receive a list of options could still accept a reference that returns those options when they need to be modified dynamically.

For example, a directive data-wp-example that has a couple of options, like this:

<div data-wp-example='{ "option1": "value", "option2": "value" }'>...</div>

Could also accept a reference that returns those options dynamically:

<div data-wp-example="options.namespace.someExample">...</div>

store({
  options: {
    namespace: {
      someExample: ({ state }) => {
        if (state.namespace.someValue === true)
          return { option1: "value1", option2: "value2" };
        else return { option1: "value3", option2: "value4" };
      },
    },
  },
});

This pattern could also be applied per option.

<div
  data-wp-example='{ "option1": "value", "option2": "ref:options.namespace.someOption2" }'
>
  ...
</div>

store({
  options: {
    namespace: {
      someOption2: ({ state }) => {
        if (state.namespace.someValue === true) return "value2";
        else return "value4";
      },
    },
  },
});

Whenever it makes sense, instead of the value of the option (or apart from it), the functionality itself could be delegated. For example, imagine this directive that does client-side navigation with options for prefetch and scroll:

<a data-wp-navigation-link='{ "prefetch": "hover", "scroll": true }'> ... </a>

Instead of passing the option to scroll dynamically, the reference could handle the scroll logic itself.

<a
  data-wp-navigation-link='{ "prefetch": "hover", "scroll": "ref:actions.namescape.scrollToSomeElement }'
>
  ...
</a>

store({
  actions: {
    namespace: {
      scrollToSomeElement: ({ ref }) => {
        ref.closest(".some-element").scrollIntoView();
        return false;
      },
    },
  },
});

The ref: prefix is not enforced, and of course, all this logic needs to be implemented inside the directive itself, but if these use cases start to arise, the use of this pattern could become a standard.