I tracked down the problem to the above docs paragraph, specifically that the problem arises when you have a prior service worker still registered and have cleared the browser's cache storage.

Why would you do that? Anyway, when new SW activates (when you close all tabs) it will pre-cache all assets and you will have your cache full again.

Is this intended behaviour of the plugin, or have I stumbled upon a bug?

If user deletes their cache manually I don't see why offline-plugin should be trying to recover from that.

Why would you do that?

Sometimes people clear their browsing history and/or other data their browser has stored (e.g. cache storage).
Maybe they haven't even cleared the cache storage by will and the environment that they have operated the browser in, has done it automatically for them (e.g. on a library computer or something).

Anyway, when new SW activates (when you close all tabs) it will pre-cache all assets and you will have your cache full again.

I tried clearing the cache and then re-opening the browser, but it does not do what you describe.
I believe the reason is because of what the MDN docs say about the new service worker getting stuck in a waiting state, due to the prior service worker.

If user deletes their cache manually I don't see why offline-plugin should be trying to recover from that.

If we are to develop websites/webpages and we don't have total control over users' browsers (e.g. to prevent them from clearing their caches), then why would we not want to accommodate for that?

I believe the reason is because of what the MDN docs say about the new service worker getting stuck in a waiting state, due to the prior service worker.

You're somehow misreading it. All tabs closed make new SW leave waiting state and became active. Here more details. Of course it will happen if you have build new SW, i.e. with a new version. If not, it's still the same ServiceWorker.

Thanks for helping me understand service workers more.

If we take this scenario:

1. User visits website, never having visited before.
2. Service worker gets downloaded.
3. Service worker receives "install" event and runs "install" event handler.
4. Service worker receives "activate" event and runs "activate" event handler.
5. User performs action which fires a "fetch" event in the service worker and because the assets have been pre-cached, the cache is used, not the network (assuming a cache-first strategy).
6. The user clears their browser storage and closes all tabs of the website, but they don't unregister/destroy the service worker.
7. User visits the website again, but the the "install" and "activate" events (of the service worker) do not fire, only the "fetch" event

This happens because the previous service worker is still registered and has already been installed and activated.

Would you agree that the scenario above is possible?

If so, would you be interested in trying to address it, specifically re-pre-caching via another means?

E.g. In the "fetch" event handler (of the service worker), maybe have a condition like so:

if (this fetch request is for the root path AND there are no cache entries in the cache) {
  run the pre-cache process/code again
}

What do you think?

Would you agree that the scenario above is possible?

Yes, I agree with that.

If so, would you be interested in trying to address it, specifically re-pre-caching via another means?

Yep.

What do you think?

I think it would be better as:

if (this fetch request is for an assets in the main cache AND there are no cache entries in the cache) {
  run the pre-cache process/code again
}