Finding historic versions for Node is indeed a good case. I guess we could try to reflect this somehow. Maybe we should have a little unit test that checks the versions running on CI are the same ones listed. Not sure how to keep it in sync otherwise.

Thanks for the PR. I supplied feedback on #2602 last week.

Thanks for the feedback.
I used the “supported” node versions from the Github test script.
If I understand your feedback correctly, this is not the node version for which it was explicitly built. It is instead based on the query maintained node versions from browserslistrc .
To find out which node version the release was built for, you need to check what the package-lock.json returns at the build time. It could even be that during a patch a mayor version of node is no longer supported.
Difficult to get it formally right. Actually, you would have to adapt the build script and publish the supported versions in the release or pin the supported versions and bump them with a mayor release....

It's possible to automate like this in our pipeline. This is how to extract the major versions:

❯  echo "node 20.10.0" | awk '{split($2, a, "."); print a[1]} '
20

So this would be sufficient to get the Node versions supported during a build:

npx browserslist 'maintained node versions'  | awk '{split($2, a, "."); print a[1]} '
20
18

Do you want to have a stab at how this could be used to automate updating some table or similarly?