Chrome on Android is interested in having a back/forward page cache to speed up back/forward navigations. Ideally we would be able to keep a page in memory as Safari is doing on iPhones. This is harder to accomplish in Chrome due to the multi-process nature of the browser. To take this into account, a very general design is the following:
1) Ensure we have a way to control document switch from the browser process -> this is the case for cross-process navigations but not same-process ones.
2) Keep a cached version of the FrameTree in the browser process when we navigate (if the page can be cached). In particular, the root should maintain access to the previous document (see point about switching document from the browser process), and child FrameTreeNode should be cached (along with their RFH & RFHPH to maitain the structure of the page and appropriate connection between the frames).
3) Ensure JavaScript execution is paused in all cached frames.
4) When the user navigates back to the page, cached frames will be swapped in from the browser process (again it's important to be able to do that in same-process navigations).
5) The cached version of the page will be deleted if the user hasn't navigated back to it after some amount of time/or due to memory pressure signals.

Considering that this is a big change affecting the core of the navigation code, this should be introduced to all platforms if we go ahead with the id (even though it benefits Android more). Otherwise, the navigation code risk diverging too much between Android and desktop and will be hard to maintain.

Next steps:
1) Figure out what are the requirements for a page to be cached - in particular regarding privacy/security requirements (eg a no-store HTTPS page should never be cached).
2) Figure out how the feature is going to interact with various subsystems in Chrome: ServiceWorker, extensions...
3) Check that JavaScript execution can properly be paused in cached frames.
4) Investigate what to do when only some of the frames of the page can be cached.
5) Land metrics to assess the expected performance improvement.

Once all of this has been done, we'll be able to have a good picture of the expected benefits, and we'll be able to make a decision on whether the expected performance benefits are worth the complexity cost to the navigation code.