Jason,
You don’t seem to understand how caching works.
Here’s the gist version:
When you visit a webpage, your browser caches everything locally. As you browse around the site, it uses it’s locally cached copies to speed up web page load times. There’s no need to re-download everything constantly, which not only hurts the visitor, but places extra load on the server.
Now if you have an image with filename myimage.jpg
and then you replace that with something else, chances are your web browser will keep serving up the one it’s cached until you FORCE it to reload it… either by clearing the cache, or doing a force-refresh if your browser supports it.
Developers have some small control over caching by telling the browser how long it should hold on to downloaded files (via headers, etags, etc)… but at the end of the day, a website can’t FORCE a browser to do anything. You can only make recommendations… and some browsers are much more militant about holding onto their cache for the sake of speed (even ignoring “distant past” expires headers).
This has nothing to do with the media manager, this plugin, or anything concerning WordPress… it’s a browser issue. If you replace a file that is already cached, you will need to force refresh the page you’re working on. Eventually it would simply happen on it’s own as the cached file “ages”.
As far as Enable Media Replace is concerned, there’s only one way I know of that you might be able to force a file to update on revision with any amount of consistency… you must change the LINK to the affected media to include a randomized querystring parameter.
For instance: myimage.jpg?1355666742
And then, every time you update that file, you need to update that querystring value (the above example uses a unix timestamp which would theoretically change on each file replace).
While it is technically possible to do something like this automatically with a plugin, it’s a sloppy solution to something that isn’t really a problem.