Brendan also talks about the what-if's, what if the timing had been different. Or what if he and I knew each other back then. I wonder what if some of the ideas that were baked into Frontier, at the deepest level, had made it into the browser.
For example, persistent memory. The browser has very little of it, through cookies, and then later through localStorage. But the PCs of the day could do a lot more than cookies. I know because in Frontier, first released in 1992, we made all globals persist between invocations of the the environment. So you didn't need to worry about loading and saving files to and from disk. If you created a global, it was there forever, until you deleted it. We did this with an object database, that was the second component of the environment that I implemented. The first, of course, was the outliner, which was used for editing everything from code to menubars and to browse and edit the object database.
How close did we get? Well, a good-size piece of Frontier was integrated in Netscape, thanks to Aleks Totic, an important feature we called menu sharing, which allowed one app to insert a menu into another. We used this feature to add script-written commands to Netscape's menus. This made content management much more facile, a precursor to the Edit This Page button, in 1999, that was the basic feature of blogging software.
There seems to be some good lightweight libraries for persistent memory (like amplify.store), plus richer object database-y solutions like PouchDB. Do those solve the problems you're thinking about, but not in the way you'd prefer?
It's not about solving a problem, it's about making programming effortless. The key thing about Frontier is that the object database is integrated into the language. You don't need to do anything to have your globals persist. They just do.