NextJS with Turbopack experiences an ever growing number of fast refresh updates per change when using bun run --bun

[Shenlok]

What version of Bun is running?

1.2.5+013fdddc6

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What steps can reproduce the bug?

Run NextJS dev server locally with turbopack enabled and bun run --bun.
Quickest repro:

1. bun create next-app fast-refresh-issue and choose Yes for everything (unsure if it makes a difference)
2. cd fast-refresh-issue
3. bun run --bun dev to start the dev server
4. Open localhost:3000 in your browser, open the devtools and observe the console. There will be a few fast refresh logs already, pairs of: [Fast Refresh] rebuilding & [Fast Refresh] done in XXms
5. Make some random changes to src/app/page.tsx and save the file each time to have HMR kick in. Just adding newlines repeatedly is a quick way to stack up HMR triggers.
6. Observe multiple (not 1:1, often an ever increasing number) of [Fast Refresh] messages appearing in the console for each change.
7. Reload the page, and observe many more [Fast Refresh] messages logged than the first time you loaded the page.

On a small app I'm building, the effect is more pronounced, which makes me think it might be exacerbated by the number of unique modules edited during the dev server session and/or the number of exports per edited module.

What is the expected behavior?

The number of Fast Refresh updates per module change is more static and doesn't grow over time as you work on the app.
The number of Fast Refresh updates triggered on page load does not grow over time for the duration of the dev server's lifetime.

What do you see instead?

A larger than expected number of Fast Refresh updates are triggered (for each individual change made to a file) as I make updates to various modules in my app. This number increases over time, and I can quickly get into a scenario where making a change to a server component leads to seemingly firing 20+ fast refresh updates.

Upon reloading the page after having previously made some changes with the dev server running, a larger than expected number of Fast Refresh updates appear to get applied immediately on page load without making changes to any modules since reloading the page.

Both of these contribute to a more sluggish feeling DX.

Additional information

Looking at the HMR websocket I can see there are more instances of incoming {"action":"building"} and associated paired/response messages being fired over time, correlating with the increased number of Fast Refresh console log messages seen.

This does not occur when using Node.
It still appears to occur when running in WSL2 as well as directly on Windows.