What is a Good Standard Practice for Responsive Image Sizing with pThumb and pictureFill

Does anyone have a rule of thumb they use for arriving at breakpoints for their responsive image deployment?

On a current project, I have a series of detail pages, each with one big image, that is approximately 960 px wide. Looks great on iMac 27. I've inserted up my pThumb and picturefill 1.2.1 for handling the resizing of each image and deployment. In reviewing some specs on iPhone alone, I'm realizing that iPhone6 Plus might require a width of 2000 - 2200px in landscape mode to avoid having the image blur. I've already discovered this with an iPhone 5 where a 400px-wide image looks great in portrait mode, but becomes degraded in landscape mode.

I'm ignoring zoom feature for now. It just seems odd that I might very well have to deliver to a mobile phone the exact image I deliver to desktop. If that's the case, then what is the point of incorporating pThumb and picturefill. Why not pop the big image into the layout and get on with other tasks?

Should I modify compression for @2x? Send a bigger image, but compress it more.

Should I avoid using 100% width on my img tag? OK I guess, but in some instances, not having the image fill the div width will mess with the intended layout.

I'm very interested in the approach other use, and open to any tips or suggestions.

On my ipad, I notice that one size image is delivered when viewing in Portrait, and another for landscape. The landscape image looks great. The portrait... not so much.

I've saved the two images from my iPad, and see that the portrait mode received a 400px-wide image, and the landscape view received a 1000px-wide image. So the portrait width detected by picturefill must be less than 800 px wide, which explains why the smaller 400px-wide version was delivered. In reviewing my markup below, this makes sense.

Clearly I need to makes some additional tweaks. But how many different scenarios should I account for. How many is too many—to the point that it totally impacts performance.

Found this article which might prove helpful:
http://blog.logo24.com/2013/08/05/responsive-images-picturefill-wordpress/

I have used Adaptive-Images with great success in the past.
http://adaptive-images.com

Found a similar alternative in http://retina-images.complexcompulsions.com, though I think Adaptive Images has a javascript that supports retina detection.

With Adaptive-Images, the filenames remain the same, and various sizes are stored in cache folders.

Still taxed with the breakpoint issue. As well, Adaptive Images works on images that are stored in a targeted folder. Not sure whether subfolders can be successfully used, as in if one has multiple galleries, and each gallery is stored in its own folder for organizational purposes.

Wondering where you wound up on this? I assume the non-standard responsive images syntax shown above is compliant with the polyfill, and that based on the behavior you described, it's akin to using srcset without a picture element?

User agents take srcset as a suggestion, whereas the picture element is declarative. Perhaps this explains away the breakpoint issue you encountered.

Curious also as to why you elected to use a polyfill at all?