Enriching Variable Fonts

Good afternoon,

So far we have largely been imagining that the client tells the server what
it has, and what it needs, in terms of codepoints. Variable Fonts (VF)
might offer the opportunity for incremental transfer to encompass more.

Imagine a page that references a VF that has {wdth,wght,opsz}. If the
browser can tell the server the specific points or ranges of axes that it
needs, then the server can opt to drop a potentially substantial portion of
the variation space when building a patch.

The client would likely need both a reasonable default (harvest all the
weights/widths actively visible or some such) and a way for a developer to
express exactly what they want (I am definitely going to use the full range
of grade, I animate on it for emphasis).

For a web page using a VF this could substantially reduce the delivery
cost, aligning well with the goal to "pay for what you use". Using 1,000
unique codeponts of a CJK font at a single optical size, weight, and width
on a page? - why pay for all the variations of those glyphs.

That is, today we (at least on our side) have largely been contemplating:

f(codepoints_present, codepoints_needed) => delta

What if we changed that to:

f(codepoints_present, axes_present, codepoints_needed, axes_needed) => delta

WDYT?