I'll assign this to myself for the moment, but lukasza@ has some things in motion already.  lukasza@, feel free to take ownership if you'd like.

nick@ and me tried to come up with a way to log user metrics that measure how often background contents are window.open-ed from 2 simultaneously alive hosted app tabs.  The basic idea is to compare openers.

2 approaches were considered:
1. Logging from chrome/browser/background/background_contents.cc (https://codereview.chromium.org/2877333004/#ps20001)
   - In this approach we track the earliest still-alive opener (and compare with the current opener)
   - Logging code is triggered when window.open "focuses" the found window via WebContentsDelegate::Activate
   - Opener is set *after* focusing the window (and AFAICT //chrome layer doesn't currently see opener-related events) - to account for this this approach has to do an icky PostDelayedTask
2. Logging from third_party/WebKit/Source/core/page/CreateWindow.cpp (https://codereview.chromium.org/2877333004/#ps40001)
   - In this approach we track the previous opener (and compare with the current opener)
   - Logging code is trivially triggered when CreateWindowHelper sets the new opener.
   - This approach has a minor layering violation - Blink normally doesn't know about "background" window feature, but logging code has to be aware of it.

I slightly prefer approach #2.

Both approaches miss the opener responsible for the initial window.open, unless the opener is plumbed through ShouldCreateWebContents call - see https://codereview.chromium.org/2882513005.

Both approaches suffer from some inaccuracies.
1. If the "previous" opener being tracked is closed, then subsequent calls to window.open will think there is no other opener even if there really is *another* one 
2. Calls to window.open from the "previous" opener always think there is no other opener even if there really is one.

"previous" above is in scare-quotes, because "previous" is defined slightly differently in the 2 considered approaches - see the description of the approaches somewhere above (look for "in this approach we track...").

nick@ pointed out that
A. approach #2 cannot easily tell if the opener is a hosted app
B. we can avoid PostDelayedTask in approach #1 if we just add a WebContentsObserver::OpenerChanged notification

I'll try to implement (B) + add checks if the opener is a hosted app.

Thanks for the detailed description!  Sounds like these metrics will be useful.  But I think one of the areas where hosted apps add the most complication is with the background permission, forcing each instance to live in the same process.  My recollection is that this goes for all instances related to that hosted app, independent of whether they were window.open'd (e.g., two tabs opened by the user would also be in the same process).  These metrics wouldn't help us make a decision on whether we can deprecate or simplify that process, right?  (Just trying to clarify to make sure I understand.)

#5: That's actually exactly what the metrics are trying to answer.  :)

Multiple instances of a hosted app only get put into the same process if they (1) have the background permission, and (2) don't set allow_js_access: false.  Even when that's true, process-per-site may be unnecessary if multiple instances of the hosted app don't all try to script the BackgroundContents.  If we can show that hosted app instances aren't accessing a shared BackgroundContents in practice, we could conceivably stop supporting that particular behavior and vastly simplify things.

#2 and #3 have the details for how we're planning to measure it, before deciding what the next step is.

lukasza@: One question about the approach-- why are we limiting it to "simultaneously alive hosted app tabs?"  If one hosted app instance created a BackgroundContents, then closed, then a second instance accessed it via window.open, we would still need the ability to put the second instance into the same process as the BackgroundContents.

Note: We may not need the metrics.  The Gmail Offline hosted app apparently requires process-per-site behavior for interactions between its foreground windows and the BackgroundContents, and that's widely used.

If we're going to proceed, we'll need to find a different way to give process-per-site behavior to such hosted apps.

Just came across this bug...

Some info that might be relevant: we'd like to deprecate hosted apps everywhere, and our current desktop PWA project should enable this.

Hi there, in continuation of comment #7, could this be the reason why gmail offline stopped working on Chromebooks? - it still works on mac.
I came across this thread https://productforums.google.com/forum/#!topic/chromebook-central/LQZmuEsdr1s and I am able to reproduce the exact same problem, only on my Chromebook.