What steps will reproduce the problem?
(1) Go to http://csreis.github.io/tests/cross-site-iframe.html
(2) Inspect the subframe (which is at a data URL), and run:
  var f = document.body.appendChild(document.createElement("iframe"));
  f.src = "http://www.asdf.com"
This creates a grandchild frame and navigates it to an OOPIF.
(3) Still in the middle frame, run:
  var blob = new Blob(['foo'], {type : 'text/html'}); 
  var url = URL.createObjectURL(blob);
  f.src = url;
(4) Still in the middle frame, run:
  f.contentWindow.document.body.innerText

What is the expected result?
This should output "foo".  This is what happens without --site-per-process (or rather, with --disable-site-isolation-trials)

What happens instead?
DOMException: Blocked a frame with origin "null" from accessing a cross-origin frame.  

This is because we didn't bring back the blob URL into data URL's process, even though the data URL is supposed to be able to script its own blob URL frame.  

Note that if we skipped step (2), this scripting works with and without --site-per-process.  With --site-per-process, we allow the blob URL to stay in the data URL's process due to CanSubframeSwapProcess returning false in this case, because the origin of the destination URL is unique, and we fall back to using the source SiteInstance because it isn't null (https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_manager.cc?l=2559&rcl=1ca17c55c4e23840893be64e18b80518ea26da85).  But this path doesn't help if the subframe is cross-site to start with.

This seems like a very rare case and so unlikely to matter in practice, though maybe there are more cases affected here that we think.