Are you planning to leave this TODO?

Not at this time. Since its path string is not an Expr it requires a bit more refactoring.

I feel like you made commonStep and specificStep at a point where the code looked different.

Because both of those predicates are only ever used here, commonStep is not reused anywhere else.

Additionally the specificStep predicate has a QLDoc that mentions it being part of a configuration.
But it's not part of a configuration, it's part of a parameterized module that can be instantiated with a config.

I just thought it would add clarity to separate them commonStep and specificStep. It also helps make clear that commonStep can be materialised once and used twice (once per instantiation of the module).

commonStep is not reused anywhere else.

It is used in two different instantiations of the module. We could inline it in the module, but then again, putting it inside a parameterised module where it does not depend on any of the module parameters is also confusing in its own way.

Additionally the specificStep predicate has a QLDoc that mentions it being part of a configuration.

I thought it would be clear that we're talking about the configuration that was passed to the module?

Ahh, now I see. Yeah, I was wrong.

The code for specificStep is constant, but it depends on predicates defined by the module-parameter.
And you can't move that code to commonStep, because materializing all of that would blow up (because specificStep follows store-read pairs, but commonStep does not).
Is that about right?

Because if it doesn't blow up without the specialization used by specificStep, couldn't you then just compute all possible steps outside this module?

The code for specificStep is constant, but it depends on predicates defined by the module-parameter.

I'm not sure what this means? It depends on the module parameter, both directly via S::isRelevantVariable and indirectly via its dependency on getModuleExports which also depends on the module parameter.

And you can't move that code to commonStep, because materializing all of that would blow up

It's not meant a performance thing at all; it's about separating types from values.

This example illustrates the need to keep them as two different graphs, because both graphs need to step through X without forgetting if a value or type is being tracked:

// lib.ts
class C1 {}
class C2 {}

const X = C1;
type X = C2;

export { X }

// use.ts
import { X } from "./lib"

var x1 = X // should refer to C1
var x2: X; // should refer to C2

Oh, OK, now I think I get it.
Could you add a comment, e.g. on FlowImpl that the module is specialized to work on only types or only on values, and that is needed to keep the separation you just explained.

commonStep(...) includes steps for both values and types, which might have caused some of my confusion.
Maybe add to the doc for that predicate that it contains type-specific steps, but that those when applied to values.

Added a comment to FlowImpl and expanded on the comment for commonStep

It seems you're using a specialized predicate (instead of TypeFlow::TrackNode) because you additionally need the steps from UnderlyingTypes::underlyingTypeStep.

Why can't those steps be part of TypeFlow::TrackNode? Or why can't functions use TypeFlow::TrackNode?

Good question. I've renamed the predicate and added a clarifying qldoc comment in 18f9133

Minor nit: Could we rename node1 and node2 to, say, source and target (or src and tgt)? It would make it slightly less likely that a typo messed things up.

I'd rather not. In fact I'd say we should standardise on node1,node2 everywhere we define edges in a graph.

This is the convention used in the data flow library, and it generally works out better when you add in things like state1 and state2.

Should this also account for things like .cjs and .mjs?