There’s two separate things here:
-
Interpolation of kerning data during font production, such that interpolated kerning can be applied to intermediate instances in the source design space (or even extrapolated beyond the source design space, if the tool allows that).
-
Interpolation of GPOS kern feature data stored in a variable font.
I view AFDKO .fea kern feature syntax — like corresponding VOLT lookup syntax — only as compiler interface code. It’s not a necessary tool representation, and unlikely to be the best tool representation. What one needs for (1) is a way of interacting with kerning within your tool of choice, including ways to maintain interpolability of kern sets between masters, and ways to perform interpolation within the tool so that one can see kerning applied to interpolated instances and generate interpolated kerning for individual instance fonts. Personally, I don’t think any part of that process should involve a type designer looking at .fea kern feature code, or even needing to be aware that such a thing exists. Kerning in font development tools should be a higher level interface, away from the requirements of a particular compiler, and the tool should look after conversion to compiler interface code in the background.
For (2), one needs the tool to be able to write variable font data to the OT 1.8 format GPOS table. This, like other aspects of OT variations technology, involves storing deltas to default GPOS data, which maps to the design space in the variable font (which may or may not directly correspond to the source design space: it might be a subsetted area of the source design space). The same comments apply with regard to the kerning interface used by the type designer: it should be the same regardless of whether what is being produced are discrete instance fonts or a variable font.