I have been waiting so long for someone to tackle this. @LarsDenBakker I can't think of a better person to do this, thank you so much for diving in!

I've left some comments re some changes to the API. Will do my best to work through the considerations promptly here to get this merged, and please don't let my reviews discourage progress.

The hot reloading API you have here is a really elegant and fast reload, and I think it will create an excellent user experience.

RollupJS are very keen to be able to support hot-reloading too, so I look forward to building those workflows out here too.

In designing hot reloading it is worth keeping in mind some flexibility of the approach, and to keep the following at the back of your mind -

1. Parent Reloading: Parent modules can perform operations on child modules that put them into specific states. Eg consider running mocha.setup({ ui: 'tdd' }) or applying an Acorn plugin. Therefore reloading the child will clear that state, and the parent module won't necessarily know to reapply it. In these cases it can be preferable to entirely clear and reload all parents of the module as the easiest way to recreate this state, and providing this as eg a boolean option to the hot reload function could be useful.
2. Reload events: If we wanted to support parents reapplying state without needing to be reloaded, it is often useful to support reload event systems like Webpack does. There are many ways to skin this one. Parents can be notified of child updates. Children can be notified of their own dehydration and rehydration. But usually any hot reloading model will want to include these sorts of things at some point. I would personally be for some import.meta.onhotreload = function () {} style things here, which should be possible under the current hooks model. We don't need to set these APIs up now, but bear them in mind as you work on this problem as they will likely be the next step once we have these core primitives.

While trying this out in a real project, I'm running into an issue where if a dependency fails to load re-importing will keep trying to run the failed module as well.

Can you clarify this case? It might actually be a core bug.

Say I have:

import './dep-with-error.js';
console.log('hot reload');

where dep-with-error contains:

throw new Error('error');

then we would expect that hot reloading the first module would result in seeing the hot reload message twice, but we should only see the dependency error once because execution errors are cached in the registry unless explicitly cleared by a loader.delete operation.

If this is not the case then that is a bug we can fix certainly.

Fetch errors are another question - in the browser they are currently looking at making fetch errors retry to support nicer behaviours.