If you have a lot of bandwidth, you can run a Mozregression to pinpoint the patch that changed the behavior. You probably want to choose the "reuse profile" option so you only have to store the local data once.

https://mozilla.github.io/mozregression/

But based on a hunch, I discovered it is linked to a longstanding privacy preference:

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.

(2) In the search box above the list, type or paste privacy.file_unique_origin and pause while the list is filtered

(3) Double-click the preference to switch the value from true to false

This preference was introduced in Firefox 68 to address CVE-2019-11730 (https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730) to resolve the issue that all local files in the same folder had "same-origin" privileges to one another's content and data.

If you disable this protection, here is how you can mitigate the vulnerability this patch addressed:

Save pages from untrusted sites in a completely separate folder, e.g., Downloads\Untrusted. That would make it difficult for an attacker to find any valuable content using local file links. You also can save pages from sensitive sites in a their own folders, e.g., Downloads\MyBank, Downloads\MyEHR, etc., to minimize unintended data sharing.

Thank you for your reply - the preference is not something I would have found myself.

Unfortunately changing the privacy.file_unique_origin setting in `about:config` had no effect: after copying a test page and pasting it in the same folder (Windows gives it a "- Copy" file name suffix), the local storage values of one page could no be seen in the other: they stayed using their own separate db tables. The configuration item may be obsolete in any case - the project pages of concern were using each others' local storage up until version 92 was pushed to Australia a few days ago.

Since posting I discovered MDN's local storage article (at least as of yesterday) includes coverage of the lack of standards surrounding file:// protocol pages' use of local storage, ending with the sentence "So it’s possible that browsers may change their file: URL handling for localStorage at any time. In fact some browsers have changed their handling for it over time" (without mentioning Firefox did so a day or so ago).

For myself I will press on with changes to make the project a single page app at the cost of marrying parts that are still under separate development and testing.

The only real solution I can think of would be for browsers to offer an option to "map folder to origin" so by default pages would not be able to read each others storage unless the user placed them in a folder explicitly set up to do so - complete with management tools that didn't involve uses opening about:config of course ;-)

That preference worked like a switch for me. I don't know what else might be different between our configurations.

My experience is that

Under Firefox 90.0(32 bit) under Window7, the switch isn't needed - privacy.file_unique_origin is true and file:// URL pages share the same local storage (table).

Firefox 90.0(64 bit) under Windows 10 behaved the same way - I had not even heard of this configuration option. After two recent updates, Firefox 92.0(64 bit) under Windows 10 will not share local storage no matter what the privacy option is set to.

If readership is interested I've uploaded a test page (localstore.html) to GitHub to determine actual browser behavior.