Hmm. The issue of build parallelism is kind-of orthogonal to .hs-boot files/circular imports.
The impact of .hs-boot files on build parallelism depends on their announced imports; at least in my semantic model of them (which might be incorrect) they just break cycles.
The degree of parallelism is visible as a property of this DAG where cycles are broken through insertion of .hs-boot nodes.
The issue here is one of transitive dependencies, which is a property on the original cyclic dependency graph.
So while we have the dependency graph
HsExpr <--> TcRnTypes <--> PmOracle
This is of no issue for build parallelism, because the .hs-boot files remove "feedback vertices" from the graph, rendering it acyclic:
TcRnTypes.hs-boot <- HsExpr <- TcRnTypes <- PmOracle
PmOracle.hs-boot <- TcRnTypes
Yet a package including HsExpr must also include PmOracle to compile.
The parallelism issue is best tackled by hadrian based profiles, on which we could compute try to come up with the optimal schedule and compare it across multiple CI runs.
But the dependency issue here is rather specific to the set of modules that should be included in ghc-lib-parser, I'm afraid, and I don't see how to solve it in a general way other than pre-computing the set of transitive dependencies for specific blessed modules. Which might be a thing we want... One set for each major entry point to the compiler pipeline, for example.