Potential special handling of "alt" features

There are a few registered feature tags that share most or all of these attributes:

• They at least sometimes use alternate substitutions
• They are only rarely used in typical "web" situations
• They are sources of dependency overlap
• They have "alt" in the tag name

The most important of these is "aalt" but there is also "nalt" and "salt". "aalt" poses the biggest problem because it's often quite large, as its role is (more or less) to collect together substitutions from other tags into one place.

It would be counter-productive to optimize for these features given how rarely they will be used. In practice some of them can be addressed while addressing the related features. (If there is a feature-specific or glyph-combination-specific patch entry for the "original" substitution then the aalt case can be added to it.) But that won't cover all cases.

If you're not trying to optimize the segmentation of glyph-keyed patches to handle these features you may need to add a bunch of extra entries in the glyph-keyed patch map to do so. But ideally you wouldn't pay the price for those extra entries unless you needed to.

So there's a question: is it worth being able to add entries to the glyph-keyed map for low-use features so that they don't need to be present in the common case? And would the current mechanisms let you get away with that with an invalidating table-keyed patch similar to how changing the glyph-keyed designspace would work? (For this purpose an extra round-trip or two isn't a big deal.) And could such a mechanism be used to lower the glyph-keyed patch map cost for other little-used features?

Start by tracing the encoder's glyph-keyed patch map and its handling of the aalt, nalt, and salt features. Compare the existing invalidating table-keyed patch mechanism with the glyph-keyed designspace behavior described in the issue. Done means deciding whether low-use features can avoid common-case map entries and documenting or implementing the chosen mechanism.