The problem with picture is that it doesn't poly fill nicely. You can add srcset attributes and it will still work on IE6. I have been using srcset for over a year, and there is is only a minor issue of retina MBPs double downloading. There is no problem with high res tablets.
I don't remember any issues polyfilling video, does anything make picture different? This is one of those things one person has to write once and then everyone can reuse it.
A polyfill of <picture> much more expensive. First you have to shiv IE to accept it as a DOM node. Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>. Polyfilling "srcset" is trivial as in:
if browser is modern and high-res,
replace the value of src.
else
pass
Doing a flash video polyfill of a video tag is okay because there is probably only one video on the page. Polyfilling <picture> would produce some seriously janky page rendering, and would be a pain in the ass to maintain.
In the proposal I saw, browsers that supported <picture> would ignore <img> tags inside a <picture>, meaning for anyone who isn't strict about pure semantic HTML, they could just stick an img in there for older browsers.
> First you have to shiv IE to accept it as a DOM node
I find this an increasingly weak argument as it's applying to <10% of the market and falling fairly rapidly ahead of the 2014 Windows XP end of life and is true of everything else in the HTML5 spec.
> Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>.
This is a reasonable complaint - I'm not sure I'd consider it a big deal since the work of manipulating the DOM is a lot faster than doing anything like downloading an image or rendering it but for anyone trying to do a wall of images it'd be worth benchmarking at the very least.
(<noscript> should keep browsers from loading the image tag, so you could do things like have JavaScript evaluate your image candidates and generate an img accordingly)
I'd prefer an extra tag during the migration stage to make the long-term goal more readable, particularly if we start wanting to extend it to do things like offer different image formats rather than just resolutions.
In the proposal I saw, browsers that supported <picture> would ignore <img> tags inside a <picture>, meaning you could use it as a fallback for legacy browsers.
