For optical size, the obvious thing to do would be to default to the ambient font size. But does that always work? e.g. if the font size is 5, and the variable font only supports optical sizes 20 to 48, will it clamp the value to 20 or behave in unexpected ways?

@guidezpl it should clamp in the way you describe, and the opsz axis units should match the px units that the font-size resolves to. I'll email you privately with some additional insights into this.

see also this: #136779

and right now if you include a variable font, things like material 3 textThemes which set weights (e.g. titleMedium) don't set the weight using fontVariations, so the weight axis of the variable font is not used. in the case of the medium weight, it gets displayed as a regular weight

repro

Scaffold(
  body: Center(
    child: Row(mainAxisSize: MainAxisSize.min, children: [
      Text(
        "a",
        style: Theme.of(context).textTheme.titleMedium,
      ),
      Text(
        "a",
        style: Theme.of(context).textTheme.titleMedium!.copyWith(
          fontVariations: [const FontVariation('wght', 500)],
        ),
      )
    ]),
  ),
);

  fonts:
    - family: Gabarito
      fonts:
        - asset: assets/fonts/Gabarito[wght].ttf

(variable font: Gabarito)

and right now if you include a variable font, things like material 3 textThemes which set weights (e.g. titleMedium) don't set the weight using fontVariations, so the weight axis of the variable font is not used. in the case of the medium weight, it gets displayed as a regular weight

Interesting report, thanks. So even within the Flutter tree, the Material implementation is using the TextStyle API in a way that gives wrong results with a variable-weight font. That seems like further evidence that it'd be appropriate to adjust that API as part of fixing the problem.

The strategy I describe at #136779 (comment) would fix this by letting fontWeight get interpreted as the font weight, regardless of whether the font offers variable weight. (With wght in fontVariations consulted as a fallback, for compatibility.)

I've filed #148026 for the proposal I laid out in that linked other issue at #136779 (comment), namely unifying into a single font-weight axis, like what browsers offer via CSS. That would resolve the symptom @wildsylvan reported above with Flutter's Material implementation.