Update: I wrote some more about the idea in this thread. It looks like JPEG 2000 already solves most of what this would need. I have an idea for how to at least demo this without needing changes in existing browsers. Then we can compare image quality, file size, etc.
Let's go through them.
Use a progressive image format and HTTP range requests. Ideally the image metadata at the start of the file would include some hints about how many bytes to download to get an exact image size. The browser can then download the smallest size equal to or greater than the dimensions it needs based on the layout's width as specified in CSS. If the user zooms or resizes the window, the browser can request more bytes as needed.
One image, one file, one URL, one resource. Perhaps the image format could even be backwards compatible so that older desktop browsers just download the large image and deal with it as usual.
If it couldn't be made to be backwards compatible, then in the interim we could just check for an HTTP Accept header and send either the new format or the full size image in an old format. But then we're back to creating two images again although at least they would be exactly the same size, so automating it would likely be easier than deciding on a set of dimensions to support ahead of time.
I assume that a new web image format or at least changes to existing progressive image formats would be required, because ideally you would want to give the browsers some hints about what dimensions the image was optimised for and how many bytes into the image those dimensions start and end. These would probably align with some multiples of two. I'm not sure.
You upload the largest possible size image and in your layout's CSS you limit the width either with something like max-width: 100%; or in your media queries you can specify pixel value widths for all images inside a specific column, or whatever. Just use CSS. Because you already uploaded "massive" images your content has the added bonus of being future-proof and zoomable and usable in a "fullscreen gallery" or "lightbox" or whatever.
Finally your images are just content like they should be and you don't have to worry about what size you're going to use in your design.
By the way: This proposal also means that you would never have to create thumbnails ever again.
Proposed by __leroux.
Yoav Weiss came up with a similar proposal, except that he proposes using ordinary progressive jpegs. He also has some examples.
Paul Robert Lloyd argues that we might not even need responsive images and in the months since I wrote this proposal I started to come to a similar conclusion.
To weigh in on the alternative images or different crops because of art direction angle: As there are more and more different screen size and resolution combinations and device categories, how would you even decide which image to display if you have multiple variations anyway?
You can't really tell that much from the screen resolution alone because you don't know the dpi, you can't necessarily say much if you had that because you don't know how far the user is going to sit from this device, etc. It is easier if you only have to support one or two devices (say the iPad and iPhone), but then that's not the web. In that sort of situation you're probably better off making an app.
If you have an image that's more legible, why not just use that all the time? If something like your logo isn't recognisable at small sizes then there's probably a problem with it anyway. If you have some solution for "mobile" where people can zoom in and pan around on your image, then why not use that on all devices? Do you even need that image? Maybe it makes more sense to adjust your design so that you don't have such a large image in the first place? etc.
Not to even mention how quickly things can become unsustainably complicated. I think from a design point of view keeping it simple is the only real option if you want your design to be truly responsive and work "everywhere" and any technical solution to save bandwidth on mobile should "just work" similar to the way things like http compression currently happens and falls back completely transparently.