Feature request: Let a variable mode be derived from another collection's mode (mode mapping)

The gap

Variable mode inheritance only works within a single collection. A mode cannot be derived from anything: not from a variable, not from an alias, not from a component property. This means that in any composed component, the mode of a nested component must be set by hand on every instance.

Concrete case

An Alert has two sizes, driven by modes in an `Alert size` collection. It contains a Button and an Icon, each with their own size collection. What I need to express is a mapping:

| Alert size | Button size | Icon size |
| --- | --- | --- |
| small | Small | 14 |
| large | Default | 18 |

There is currently no way to state this relationship anywhere in the file. Setting the Alert to `large` leaves the nested Button at whatever mode it happens to carry.

Why the existing workarounds don't hold up

One shared collection.

This requires the scales to align on two axes. They don't. My icons have five steps (12/14/16/20/24) and my buttons have three (Default/Small/Large). Forcing both into one mode axis means either padding one component with duplicate modes or cutting steps I need. It also breaks naming: if `lg` means 18px for an icon and 36px for a button, the mode name no longer carries meaning for either, and designers have to memorise the per-component translation.

Binding a string variable to the variant property.

This works only if the nested component exposes size as a variant property rather than as modes, and it resets instance overrides when the variant switches. It also doesn't solve the case where the nested component's size legitimately lives in its own collection.

Variants on the parent.

Hardcoding the child's explicit mode inside each parent variant works, but forces variant duplication even when the component is visually identical across several of them, and it defeats the purpose of using modes in the first place.

Separate files per collection.

This is deliberate on my side and helps with independent versioning of upstream components. Any solution that requires merging collections into one file undoes that.

Why this matters more with slots

With slots, the nested content is authored by the consumer of the component, not by the library author. There is no main component in which the correct child mode could have been pre-configured. So every designer placing a Button into an Alert slot has to know the mapping and apply it manually, on every instance. The mapping lives in people's heads instead of in the system.

Proposal

Allow a collection to declare, per mode, which mode of another collection applies to its descendants. Conceptually: `Alert size / large → Button size: Default`, `Alert size / large → Icon size: 18`. Inheritance rules stay as they are: an explicitly set mode on a child still wins, so the escape hatch is preserved.

An alternative shape that would also solve it: make a node's mode per collection bindable to a string variable, the same way variant properties can already be bound today.

Note on feasibility

The plugin API already exposes `setExplicitVariableModeForCollection`, so writing a computed mode onto a node is possible in the data model. What's missing is a declarative way to express it in the file, without requiring someone to run a plugin for the design to be correct.

How this reads in code

In a frontend implementation this is a solved problem: an Alert passes its size down through context, or the composition maps the prop, or a scoped custom property cascades and the child overrides it if needed. The mapping is one line. Right now Figma is the only layer of the system where that relationship cannot be expressed, which means design and code drift by default rather than by accident.