I did some more investigation and it now looks like I was wrong. This is not a regression. :(

However, since chrome.webRequest.onHeadersReceived is not called and the original response headers are used, there is no way for an extension to persistently modify the headers of such cached pages.

When I open chrome://net-internals and follow the above steps, I see the following log entry at some point. So it is a duplicate of issue 453843.

Out of curiousity - why do you want to modify headers in Tampermonkey?

1036: URL_REQUEST
https://www.ingdirect.com.au/securebanking/
Start Time: 2016-05-13 00:30:05.491

t=0 [st=0] +REQUEST_ALIVE  [dt=3]
t=0 [st=0]    DELEGATE_INFO  [dt=1]
              --> delegate_info = "NavigationResourceThrottle"
t=2 [st=2]    URL_REQUEST_DELEGATE  [dt=0]
t=2 [st=2]   +URL_REQUEST_START_JOB  [dt=0]
              --> load_flags = 37121 (MAIN_FRAME | MAYBE_USER_GESTURE | VALIDATE_CACHE | VERIFY_EV_CERT)
              --> method = "GET"
              --> priority = "HIGHEST"
              --> url = "https://www.ingdirect.com.au/securebanking/"
t=2 [st=2]      APPCACHE_DELIVERING_CACHED_RESPONSE
t=2 [st=2]   -URL_REQUEST_START_JOB
t=2 [st=2]   +URL_REQUEST_DELEGATE  [dt=1]
t=2 [st=2]      DELEGATE_INFO  [dt=0]
                --> delegate_info = "NavigationResourceThrottle"
t=3 [st=3]   -URL_REQUEST_DELEGATE
t=3 [st=3]    URL_REQUEST_JOB_BYTES_READ
              --> byte_count = 2605
t=3 [st=3] -REQUEST_ALIVE

> Out of curiousity - why do you want to modify headers in Tampermonkey?

As you know, Tampermonkey executes user defined scripts. 
These userscripts are stored at the background page and are retrieved by the content script via asynchronous communication. (executeScript is at the moment not reliable enough 471801) 
This means the page's scripts might have been executed already when the userscripts arrive at the content script. 
Unfortunately script tags that are injected by content scripts after document_start can be discovered by the page using a MutationObserver and this allows the page to parse the content of the script tag and to hook into the Tampermonkey page script and content script communication.

In order to avoid this a very small piece of code is injected at document_start which establishes a communication bridge, but this requires the userscript code that can only be transferred as a string to be eval'ed.
That's why TM relaxes the CSP of pages where a userscript is supposed to run to allow unsafe-eval.

Don't use eval, but an inline script and you don't have to touch the CSP headers.

Try the following extension for example. It shows that eval is indeed blocked in all cases, but <script> tags (inline and with src) are not blocked if the content script injected it.

To try it out, put csp.html on some website (e.g. localhost), load the extension and visit csp.html

Deleted: csp.html 217 bytes

csp.html 217 bytes View Download

Deleted: manifest.json 292 bytes

manifest.json 292 bytes View Download

Deleted: contentscript.js 410 bytes

contentscript.js 410 bytes View Download

Deleted: injectedscript.js 119 bytes

injectedscript.js 119 bytes View Download

> Don't use eval, but an inline script and you don't have to touch the CSP headers.

I know, but as I said: inline scripts that are injected after document_start can be detected and read by the page's scripts using a MutationObserver.