#5334 (Cross-Origin Opener Policy) introduces browsing context group switches during the navigation when the response has a particular header. The impact of a browsing context group switch during navigation is not defined, especially when it comes to session history.

Navigating back between browsing context groups is undefined because the spec associates session history with a particular browsing context. @annevk proposed in #5334 to introduce a browsing session concept which would maintain session history for a tab (as browser currently implement history). The browsing session would persist even if we swap browsing context groups during navigation, and would allow to navigate back/forward between them.

One question for back navigations between browsing context groups when we have a browsing session concept is whether we re-use the original ones or create new ones.

Currently, in Chrome's implementation of COOP, the browsing context group causes a severance of all opener relationships. They are not re-created when the user navigates back because there is no mechanism to remember that the back navigation must go to a particular browsing context group.

For example:

• We have a browsing context group 1, which contains browsing contexts showing the documents a.com and b.com. They can communicate with each other using Window.Proxy.
• The document a.com navigates to c.com and this navigation requires a browsing context group switch. We create a new browsing context group 2, which contains the document c.com. Browsing context group A now only contains b.com. a.com and c.com documents cannot communicate with each other.
• The user navigates back. This still requires a browsing context group switch. The behavior we have implemented is to create a new browsing context group 3, which will contain only a.com. The a.com document cannot communicate with the b.com document, even though they could when the user initially navigated to them.

This behavior is simpler to implement, but we worry it might cause breakages when the user navigates back and forward. We would prefer to have the following behavior:

• the browsing session maintains a list of session history entries which track what was the browsing context group of the session for each entry.
• when navigating to an existing entry which require a browsing context group switch, we check if the browsing context group still has active browsing contexts. If so, we create a browsing context for the navigation inside this browsing context group.
• otherwise, we create a new browsing context group with a new browsing context.

Note that we might want to do something similar for window.name.