On example.com, document.cookie returns '' though, does that mean this could be origin indicator bug?

This doesn't look like an extension or NTP problem but a general issue with the CookieTreeModel:

1. Go to youtube.com
2. Go to example.com

Notice that there are several cookies from youtube.com

CannedBrowsingDataCookieHelper::Reset is called when the navigation starts but it looks like some CannedBrowsingDataCookieHelper::AddReadCookies calls from youtube are still coming afterwards.

Has any of the code in question been servicified?  Servicification removes guarantees about event ordering.  It doesn't look to me like this has been hooked up to the new cookie path, but it could be that some other events (Like navigation...) are now using a Mojo pipe instead of the shared IPC pipe, breaking ordering assumptions.

I just tested to turn off PlzNavigate (navigation-mojo-response). Now I can't reproduce the issue with youtube anymore but I still see the issue when navigating away from the NTP extension. (65.0.3325.73)

Hm, but maybe just a timing issue... In a chromium build with PlzNavigate disabled I still see youtube cookies on example.com.

Network requests themselves are using a Mojo API, so not necessarily just navigation using Mojo that makes this racy.  We've removed the non-Mojo loading path, so can't just disable that.

If we can fairly consistently repro the issue, we can presumably bisect it.  Not sure knowing which Mojo path is to blame would get us much, as the system will likely need to be significantly redesigned, but it could at least let us figure out if this is indeed Mojo related (Not that I have much doubt of that).

It looks like this is not mojos fault: I tried to bisect on linux and couldn't get very far because chrome wouldn't start on older builds. 
Then I tried win64 and it didn't have old enough builds. So I tried win x86 builds and it looks like the issue existed since the cookie tree ui was added. At some point I even lost the possiblity to install extensions because the appstore complained about my old version of Chrome.

300547 extension bad, youtube bad
169899 extension cant install, youtube bad
111636 no cookies tree...

You are probably looking for a change made after 153117 (known good), but no later than 153142 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/ecd2fd73bd1b299b7734fa7916c399aa9a704c09..9665973cfe562be5aaa231b7caec720c84614e31

At least I know now that crrev.com/9a8e9352d12c519c70656ee70b643b67493f1993 enabled the new pageinfo ui and windows backwards compatibility is great.

Broken for five years.  :(  I'm not seeing anything in there that looks suspicious, though.

You mean the list of changes? Yes there is nothing because the only reason I marked builds before this range as good is because the pageinfo ui didn't exist. 

I was able to create a very simple reproduction case by writing to document.cookie in an onunload handler. This way the origin of the page with the unload handler will appear in the cookie list of the page you are navigating to next. 

This can be prevented by checking RenderFrameHost::IsCurrent() in TabSpecificContentSettings::CookieChanged(). IsCurrent() is false when the unload handler fires. According to the description of IsCurrent(), there might be other cases where a frame can not be current. Is there a more explicit way to check if a frame is being unloaded?