[js-api] Possible alignment of abstract closure conventions with ECMA-262

In the JS-API specification, there are a few cases where abstract closures are used.
I was wondering if these could follow the same conventions as in ECMA-262 for consistency.

React step in js-api specification

For example, in the algorithm “Instantiate a promise of a module”, there is a step called react.
This step takes as input some substeps to perform when the promise is fulfilled or rejected.
Each of these substeps is later passed to ECMA-262’s CreateBuiltinFunction, which expects an abstract closure as an argument.
In other words, the react step treats those substeps as abstract closures in the ECMA-262 sense.

However, the way these closures are represented in the JS-API specification looks quite different from the convention used in ECMA-262.

Abstract closure in ECMA-262

Abstract closure in WebIDL

In ECMA-262, abstract closures are explicitly marked as such, with their parameters and captured variables listed.
While the JS-API specification depends on the Infra Standard (which may justify stylistic differences), another Infra-based specification, WebIDL, also follows the ECMA-262 convention.

Would it make sense for the JS-API specification to adopt a similar notation, explicitly marking these substeps as abstract closures like below?
This could make it clearer that they correspond to ECMA-262 abstract closures and help maintain consistency across related specifications.
For example, it might be written as follows instead:

Start in the JS-API specification with the “Instantiate a promise of a module” algorithm and its react step. Compare its substep notation with the abstract closure conventions shown from ECMA-262 and WebIDL, then identify the other affected cases. Done means the agreed closure notation is applied consistently across the relevant JS-API specification text.