Thanks for filing a separate bug!

I myself cannot reproduce this on M57 Linux and Windows :(
As far as I read
https://www.chromium.org/developers/design-documents/process-models
it should not happen.

Do you give your chrome any specific command line options?
If you are not sure, chrome://version/ page gives you the information about
commandline options.

Oddly, I could not reproduce on Gmail today, but it still occurs from outlook outlook.office.com.

I have tried with and without arguments (making sure it does not use a running session) with the same results.

I sometime lunch Chrome with:

google-chrome-stable --pinned-tab-count=3 site1 site2 site3
(I don't even think this still works..)

chrome://version/ yields:

Google Chrome	57.0.2987.110 (Official Build) (64-bit)
Revision	11f66db67ea1f20d200d6f9add50fc1c345d71f7-refs/branch-heads/2987@{#832}
OS	Linux 
JavaScript	V8 5.7.492.65
Flash	25.0.0.127 /home/jpambrun/.config/google-chrome/PepperFlash/25.0.0.127/libpepflashplayer.so
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36
Command Line	/opt/google/chrome/google-chrome --flag-switches-begin --flag-switches-end
Executable Path	/opt/google/chrome/google-chrome
Profile Path	/home/jpambrun/.config/google-chrome/Default
Variations	3095aa95-3f4a17df
8364a5c2-ca7d8d80
7c1bc906-f55a7974
ba3f87da-45bda656
cf558fa6-ca7d8d80
58aac55e-3f4a17df
f3499283-8d3181a0
31362330-ca7d8d80
349d561b-3f4a17df
9e201a2b-803f8fc4
6eb432aa-ca7d8d80
5274eb09-3f4a17df
9773d3bd-ca7d8d80
2e109477-ca7d8d80
9e5c75f1-c16ec2e6
6b121ae7-ca7d8d80
f79cb77b-3d47f4f4
b7786474-d93a0620
23a898eb-4c21fc8d
4ea303a6-868b4867
9736de91-ca7d8d80
69bf80fa-91c810ef
867c4c68-3f4a17df
b2f0086-93053e47
7fc902e8-ca7d8d80
f11cb941-11910166
3ac60855-486e2a9c
f296190c-22cd16e0
4442aae2-d7f6b13c
ed1d377-e1cc0f14
75f0f0a0-e1cc0f14
e2b18481-d7f6b13c
e7e71889-e1cc0f14
828a5926-ca7d8d80

Thanks for the info.  I tried outlook.com and the issue reproduced.
I included two links in the mail

https://www.google.com
https://www.youtube.com

and only youtube.com was shared in the same renderer process.
I have no idea, though.

There's a lot of caveats in the process model to preserve backwards compatibility, so this may be expected behavior.  I'll take a closer look to comment on it when I get a moment.  In the meantime, more info here:
http://dev.chromium.org/developers/design-documents/process-models

I am unaware, of course, of any other considerations, but from both users and webapp supports perspective, tabs crashing because of other unrelated tabs is a significant caveat.

Sorry for the delay, as I was OOO for a bit.

The process models page explains that most link clicks stay in process today.  One reason for this is that same-origin pages with references to each other can script each other and must live in the same process.  If a link on site A (e.g., Gmail) opens in a new tab on site B, it might seem like we could put it in a new process, but that page on site B might have an iframe to site A that scripts the opener page.  We've seen this in various OAuth cases in the past.  To avoid breaking scripting in such cases, we generally leave link clicks in the same process unless there are other signals that it's safe to swap.

Gmail uses techniques to indicate that links in emails are safe to open in a new process, which is why it generally works there.  These techniques include things like rel=noreferrer or rel=noopener attributes on the links (e.g., see https://blog.chromium.org/2009/12/links-that-open-in-new-processes.html).  Outlook probably doesn't do the same thing, though it could be a feature request for them.  (In comment 3, google.com probably switched to a new process because it's treated specially as the default search provider.)

In your original screenshot showing process sharing with Gmail, I'm guessing you middle-clicked the links, which currently traps them in process.  We're making some progress on fixing that in https://codereview.chromium.org/2686943002/ (and  issue 23815 ).

Overall, we do look for ways to swap processes when we can, but we have to balance it with compatibility (e.g., not breaking OAuth) and memory use.  There will always be times when tabs need to share a process, but we try to keep those limited where we can.

For the future, we're getting to the point where we'll have much more flexibility to use separate processes now that out-of-process iframes have launched (see http://dev.chromium.org/developers/design-documents/site-isolation and http://dev.chromium.org/developers/design-documents/oop-iframes).  There's still some more work to do for Site Isolation before that can happen, though (see issue 467770).

For the time being (apart from the issues noted above) this is working as intended, so I'll close this particular bug.  Hope that helps to convey the reasoning.

Thanks for the detailed response. It is really appreciated. I now understand the other limitations/considerations.

This somewhat 'unpredictable' behavior combined with the 1.8 GB per process limit on Linux is hard to work around for memory intensive applications..

Again, thanks for the great response.

Looks like this is mostly fixed. I noticed on Version 62.0.3202.94.
I can now allocated up to 8 GB per process group. Once I reach the limit, I now get a catchable buffer allocation error instead of 'aw snaps'.

Keep up the good work!