Per the PR text this kind of explains what is going on:

  /**
   * ...
   * 
   * In WHATWG HTTP spec for ESM the cache key is the non-I/O bound
   * synchronous resolution using only string operations
   *   ~= resolveImportMap(new URL(specifier, importerHREF))
   * 
   * The url used for subsequent resolution is the response URL after
   * all redirects have been resolved.
   * 
   * https://example.com/foo redirecting to https://example.com/bar
   * would have a cache key of https://example.com/foo and baseURL
   * of https://example.com/bar
   * 
   * ...
   */

Likely this should be a bigger refactor because callbackMap is becoming spaghetti but that should/can be punted for now.

This is 1/2 of the issues we have seen with HTTPS CDNs for ESM and is a partial fix for #42098 .

I would note that the URL mentioned in the corresponding issue continues to fail even with this and #42119 because it redirects to an absolute URL with a 404:

302 https://unpkg.com/uuid?module ->
200 https://unpkg.com/uuid@8.3.2/dist/esm-node/index.js?module -> (this is where the PR fixes apply in both PRs)
200 https://unpkg.com/uuid@8.3.2/dist/esm-node/rng.js?module ->
404 https://unpkg.com/crypto@latest?module

Before this PR the base URL used for resolving ./rng.js was incorrectly using the cache key of the module https://unpkg.com/uuid?module. Per WHATWG this should actually be changed to https://unpkg.com/uuid@8.3.2/dist/esm-node/index.js?module

Set base URL to referencing script's base URL.

And WHATWG:

It is intentional that the module map is keyed by the request URL, whereas the base URL for the module script is set to the response URL. The former is used to deduplicate fetches, while the latter is used for URL resolution.

After both PRs the behavior in Node matches the browser: https://jsfiddle.net/n8cwL4bm/