The group linking algorithms often refer to derived information that itself involves processing that wouldn't actually happen in that order practically. I am not sure what the goal of the spec is in a scenario like this, but in the process of converting these functions into code, they end up being implemented quite differently.
The immediate bugs are:
15.2.5.3.2 (3) Load.[[UnlinkedDependencies]] is not a defined property for load records. Working around this alters the implementation.
15.2.5.3.1 (1) "Assert start is a list of Linkset records" should read "Assert start is a list of Load records"
In the process of implementing the algorithm, I found it a lot more convenient to base the linking process on the following principles:
1. Let Link act on a LinkSet instead of a set of Load records. This way we can assume that the first Load record has a [[groupIndex]] of 0, and calculate the group indices of other load records in the linkSet directly from this groupIndex working down the tree.
2. This way, we only need to traverse the tree once for everything we need, calculating the group indices, declarativeGroups and dynamicGroups as we go.
I'm happy to help however I can and discuss further about corrections that can be made to ensure the pseudo-code is complete.
I also forgot to mention I reverse the order of the groupIndex to start at the top from 0 instead of the bottom being the maximum groupIndex so that we don't need to know the groupIndex of the whole linkSet from the beginning, but let it only be known after the full traversal. Then we link the groups in reverse rather.
(This bug was filed against Rev 22, but you may have meant to file against Rev 24, the current version. The Description appears to be valid against either.)
concerns old module spec.