Repro steps: 
1) start Chrome with --isolate-origins=https://google.com
2) Install hangouts extension and disable it
3) Open three tabs at https://google.com, such that they all end up in separate processes.  
4) Open task manager
5) In a fourth tab, go to chrome://extensions and disable/reenable the Hangouts extension.  Its background page has a google.com subframe, which should reuse one of the three google.com processes.
6) Repeat step 5) several times.

Expected: step 6 results in the subframe randomly assigned to one of the three google.com processes.

Actual: step 6 always assigns the subframe to the *same* process picked in step 5.

Note that this doesn't occur with subframes on regular tabs.  For example, with three https://csreis.github.io processes, going to http://csreis.github.io/tests/cross-site-iframe.html, and reloading it and then clicking "Go cross-site (simple)" will place the subframe into one of the three processes randomly, as expected.

The difference seems to be that with the background page, step 5) returns three eligible background hosts in RenderProcessHostImpl::FindReusableProcessHostForSite, but step 6) always find one eligible foreground host and returns it.  So somehow the google.com subframe on the background page incremented its first process's VisibleWidgetCount(), which it probably shouldn't have done.  In the csreis.github.io case, reloading always picks among three random eligible background hosts, and doesn't cause a new eligible foreground host to appear.