Webpage makers already have the tools they need to do this: the page URI can be manipulated client-side to store state. And they can specify which content should be cached for use in the future without a trip to the server—including full client-side app functionality.
I couldn't even imagine supporting that in an app I wrote, much less in a way that works for every website everywhere!!
(1) moot in the sense that it ought to act to server side changes much like any static pages would become out of date when backend updates are made. If the api endpoint goes away, then it errors, it's not the responsibility of the browser to keep the app evergreen, imho
Sure, it should do precisely that, IMO. Serialize it and dump it. All of this is in browser cache AFAIK anyway, so it's not like it's some completely novel programming exercise.
As for keeping up with the server side - I don't care. The "sync to the server state" button exists, and is called "Refresh" button. Nothing needs to be implemented by website author. In fact, I'd prefer if websites didn't have a say in this at all - or else someone will find a reason to screw with the mechanism.
Firefox will show the previous contents of tabs in place when you update firefox live. So it must already have that ability.
About websites: I don't want to have to rely on website makers, because they invariably won't do it and it won't work.
It doesn't matter. Store and index what I read. Content could be destroyed and altered in the server.
Think of it as a cache of things seen. Bonus points for hyperlinked media assets. Double bonus points for those links being to cached media assets.