It would make caching much easier if the file at a given URL was immutable; that is, if a replacement image has a different URL from the old one.
I thought I had suggested this a long time ago already. :)
In my opinion, you should redesign the image/oldimage table structure in the same way that cur/old was changed into page/revision. Each image revision, whether "current" or not, should have a numerical ID for a primary key. You can then use that integer in your unique URLs. (I am against the idea of timestamps because they are never unique. ;-) ) This has the added bonus side-effect that (a) when an image gets overwritten by a new version, the old image's URL is still the same; (b) reverting to an older image revision allows you to just revert to the old URL instead of creating a new one, thereby somewhat helping caching. You could even use MD5/SHA1/whatever checksums to detect duplicate uploads and re-use the already-existing image revision with its already-existing URL.
LiveJournal did the same originally with their user picture URLs. I realise they ran into the concern that it would allow people to enumerate all user pictures, giving an easy way to write a good-faith script that would kill the servers. As a counter-measure, they added the numerical ID of the user the image belongs to to the URL as well. Since that never changes either, you still have the nice 'permanent URLs' effect.
So we will have to think about whether we have the same concern. If we do, we can add the numerical user ID of the image's uploader to its URL, or (as we do already) part of a checksum. We currently checksum the image's filename, however, which I strongly object to, because it makes it harder to code an image-renaming feature. If we're going to redesign this anyway, we might as well make it so that this feature will be easier to code in the future.
Note also that the most commonly requested image-related feature is the ability to undelete an image, thereby removing the last bit of irreversibility in an admin's toolset.
Timwi