Chrome Version: 63.0.3239.132
OS: Win 10

What steps will reproduce the problem?
(1) Start Chrome with --disable-features=UseGoogleLocalNtp --isolate-origins=https://google.com
(2) Sign into google.com
(3) Open an NTP and navigate to https://maps.google.com
(4) Open another NTP and notice (in Chrome's task manager) that there's a https://google.com subframe entry.
(5) Navigate the second NTP to https://maps.google.com

What is the expected result?

The second Google Maps tab should be in a different process than the first, since the tabs are in different BrowsingInstances.

What happens instead?

Both Google Maps tabs are in the same process.

This seems to happen because the remote NTP has an effective URL, similar to hosted apps.  When the user is signed in, there are other google.com iframes which do not get the same effective URL, so they're kicked out of the process in M63.  (We no longer kick these subframes out of the process in r521188, which was merged to M64.)

The google.com OOPIF aggressively joins an existing same-site renderer process if one exists (to avoid creating processes for OOPIFs when possible).  However, this means that the BrowsingInstance for the new tab now has a SiteInstance pointing to an existing process, so future visits to https://*.google.com end up in the existing process as well, which is undesirable.

This does not happen with the local NTP, or when the user is not signed in, or in Chrome 64.  However, there's a more general version of this problem, which I'll file next.