The question is...
Do ETag caching and Flash cookies bypass porn-mode protection on chrome/IE/whathaveyou? I wouldn't be surprised if they did, and someone somewhere is sniggering at my giant hat fetish.
Meanwhile, note that ETag caching as tracking is not going to go away any time soon. What these researches do is the following:
Send HTTP Request without ETag. Get HTTP Response with an ETag and some cookies. Delete cookies. Send HTTP Request with ETag. Get HTTP Response with cookies, which are same as before (Coincidentally this is what they are calling "cookie respawn", which somehow suggests that they are brought back to life, while in fact they are just being reset by server to same values). <= Proof of tracking.
Meanwhile, the next-gen ETagger (NGE) could be a little more sneaky. Let's suppose that the cookie contains a unique identifier, which is typically just a large number. By using miracles of mathematics NGE could mangle this identifier each time it's not being verified by a cookie.
Send HTTP Request without anything. Get HTTP Response with ETag, cookies, etc. Delete cookies. Send new HTTP Request with ETag. The server receives a cookieless request which still has an ETag. The server then sends out a new cookie with the uid that can be randomly transformed back into the original uid. The researches now receives a HTTP Response with a new cookie. He or she is now convinced she's not being tracked.
The transformation function need not be very complicated to be sufficiently advanced to bypass visual inspection. Of the top of my head [f(int uid, int seed) -> string] could be [seed + delimeter + md5(uid) xor seed]. At inspection it seems trivial to recover the uid, but you'd have to know the function definition to do so. Oh and of course you can construct much more advanced schemes, that are very hard to break even if you know what you are looking for.
So, welcome to trackable internets!