Not sure who owns the duplicate logic, but this is probably expected.  Note no-cache pages can be stored in the cache, that copy just can't be reused for normal loads.  When navigating back to a page via forward-back, we will load such resources, and "duplicating" a tab probably uses similar logic.

Yes, that does seem to be the case, the navigation type is TYPE_BACK_FORWARD. It does seem strange to me. That type is supposed to represent that a history traversal operation[1]. I don't really see how cloning a tab fits that description. It seems like you're creating a whole new thing, and should get a refreshed document as part of it.

Our use-case is that we supply some initialisation data to our single-page application through a JSON blob that's emitted on the root document. It helps the app know if the user is logged in while it initialises. We have a situation where the user can open the app, login, navigate around for a while, then duplicate the tab. The init data in the new tab tells that app they're still logged out, so they get redirected to the login page, not the resource they were looking at.

Oh well, I can think of a few workarounds.

[1] https://www.w3.org/TR/navigation-timing/#sec-navigation-info-interface

Cloning a tab should clone the contents of the top, no?  It's not "open this page in another window", but "duplicate this tab and its contents".  Reloading the page may result in a tab with different contents.  Ideally, we'd just copy the current page and all of its state (loaded images, css, subresources, form state, current state of the document, etc), and not even go to the disk cache.

[Mac triage] Based on the discussion so far, I'm going to mark this WontFix. Feel free to reopen if that wasn't right.