How to resolve referenced tokens with modes?

[JeroenRoodIHS]

I have a set of alias tokens that reference tokens that have modes, which seem to be exported to JSON referencing one of the modes in the alias. I can't really deduce how the output is generated, but here is an example of my set up and one of the results:

1. courseStates
These variables reference semantic state variables which support two modes: light and dark.

Variable name	upcoming	fired	cooking	plated
background/course	🔗background/courseState/upcoming	🔗background/courseState/fired	🔗background/courseState/cooking	🔗background/courseState/plated
background/addon	🔗background/addonState/upcoming	🔗background/addonState/fired	🔗background/addonState/cooking	🔗background/addonState/plated

2. sem
These semantic variables support two modes: light and dark. Here is an example of the variable 🔗background/courseState/fired:

Variable name	light	dark
background/courseState/fired	#72BBFF	#A1D1FF

When I look up courseStates/fired/background/course ("courseStates" being the automatically prepended collection name and "fired" being the automatically added mode, as exported by the design-tokens plugin), its value points solely to the dark mode of the "sem" collection:

{
  "courseStates" : {
    "fired" : {
      "background" : {
        "course" : {
          "type" : "color",
          "value" : "{sem.dark.background.coursestate.fired}"
        }
      } 
    }
  }
}

The way that this alias token is resolved is only 50% of the truth: I am missing the light mode of the token. I wonder: how can I resolve this token correctly, so that I have both its referenced modes at my disposal?

[JeroenRoodIHS]

I am beginning to think that a structure of value <- alias <- alias is too complex for a design token system. Three dimensions seems like something that tooling can't cope with. What am I to do? Should I "flatten" my token structure to not make alias variables with modes of alias variables with modes of base variables?

Granted, what I thought of does reduce clutter in my design system: I can create components that respond to both themes (light, dark) and semantic states (neutral, warning, error, success). But given that (any) tooling is not up for it, is it even worth trying to set up such a level of abstraction in my design system?

[JeroenRoodIHS]

I have given this some more thought. I quite like how Cobalt handles tokens with modes. Rather than putting modes in the JSON structure, information about modes is accommodated in the extensions property.

{
  "$type" : "color_for_example"
  "$value": "{a.representative.token.value}"
  "$extensions": {
    "mode": {
      "light": "{alias.token.1}",
      "dark": "{alias.token.2}"
    },
  }
}

Given that I have the feeling that this plugin is forced to pick one of the modes as a representative value when you are deeper in the structure and have a multi-dimensional problem with overlapping mode-axes. This forced choice is restricted to the $value of a token, but not to an $extensions.mode property.

I think this ties in pretty well with how Figma variables work: you have one dimension of modes per token, but a token can reference any alias token that has its own dimension of modes.

What is your thought on this?