Turbopack First-Wins Module Registration Installs Wrong Factory For Async Loader With Divergent Bodies In Different Chunks

AsyncLoaderModule::asset_ident_for identifies the loader only by target module, ignoring chunk availability, while chunk_item_content generates different loader bodies based on whether the target chunk is already available. Global module ID generation therefore maps divergent factories to the same ID. The runtime installCompressedModuleFactories preserves the first registered factory, so whichever factory is registered first determines behavior, creating a race condition.

1. Clone https://github.com/Stanzilla/turbopack-first-wins-repro 2. Run `npm install` and `npm run verify` 3. The verify script builds the app and runs static/natural/synthetic runtime assertions in both chunk execution orders 4. Observe that dynamic import can fail with `Module <X> was instantiated because it was required from module <Y>, but the module factory is not available.` when the Promise.resolve factory wins before the target factory is registered.

Changing module IDs will invalidate existing persistent caches and may alter chunk hashes across a deploy. Test thoroughly in a large Pages Router app with Turbopack scope hoisting enabled to ensure no new duplicate IDs or bundle size regressions. Rollback by reverting this patch or, as a temporary workaround, set `experimental.turbopackScopeHoisting: false` in next.config.js. Also verify that the availability string is stable and deterministic across builds and platforms to avoid non-deterministic IDs.