About dynamic IFT after the proposed changes

As today's discussion is sinking in there's one thing I'm curious about:

With static IFT under the new proposal the encoder will take the font file and some configuration and arrive at a patch graph, perhaps all at once and perhaps step by step but either way (I presume) starting from the root. In that model the URL for each patch file is just a token embedded in two types of place (the map in the source file, the name of the target file). So they could be picked at random for all it matters.

With the new proposal for dynamic IFT the "target file" won't exist. That means that the URL in that case needs to map, somehow, to a pair of parameter sets (codepoints, features, axes): the parameter set of the source file, and the parameter set of the target file.

Assuming the configuration is fixed, and therefore the graph for a given file will be deterministic, one way to do this is to drive the URL has a hash of the two parameter sets and then walk the whole graph on each request to find the right node. With a lot of nodes this might be costly.

Alternatively, the URL could encode a path along the graph, and then you would just need to generate and walk those particular nodes, assuming that's possible.

A third option is to require that the encoder generate and output the entire graph even in any partially or fully dynamic use case, and then the server side could consult the file to get the mapping (with the storage format presumably optimized for this). The map might be large but if it's only on the server side that's probably not of much importance.

So what I'm wondering is which of these strategies is the current thinking, or is there some better option?

Skef