I'm having a little trouble wrapping my head around your interfaces and their responsibilities, so maybe I'm just confused, but why do you need a Resource<IImage>?
Part of my confusion with your API at the moment is the difference between a Resource and a ResourceHandle. Which is responsible for determining when hot-swapping/reloading must occur? It already appears as though Resource does some of this because they have setters for an IO and a FileMonitor.
Ok, so quick overview:
'resources' are any static data that is loaded at runtime. Sounds, images, enemy movement speeds, etc. This is done by implementing a base Resource interface and doing whatever custom loading/parsing is required to load the raw data. The rebirth resource manager handles the generic low-level stuff like turning a series of xml files into calls to your resource c'tors and other methods.
ResourceHandle is a concrete type that's part of the core resource manager, and holds a reference to the actual resource it's managing, as well as a bit of book-keeping info (like what load state it's in). Most importantly, it means the gameplay code can hold onto a ResourceHandle<Foo> instead of a Foo directly. This means that when the resource manager detects a modified file it can re-parse the resource files and create a new Foo, then swap it out for the previous version of the Foo object.
The gameplay code doesn't care that in frame 10 it's got Foo instance 1, and in frame 11 it's got Foo instance 2, since it calls fooHandle.get() before using it each time.
90% of the time the resource manager can hot-reload resources in a generic way without the resource itself having to be coded specially. For the remaining 10% (ones that depend on non-trivial file parsing) they can use the resource IO and FileMonitor to hot-reload without making a new instance.
If you're really interested, the docs and tutorial might be worth a read: http://triangularpixels.net/games/tools/rebirth/
Rather than having IImage implement Resource, you could use composition instead.
This only really shifts the dependancy down a layer. It works in some circumstances (and I've already been using it) but not when I want to pass a resource handle into a subsystem itself (as I still have the dependancy on Resource somewhere in the chain).
I would also add that IMHO beyond trivial collection uses, generics introduce more complication than they remove.
This definitely seems the case. However it does grant additional type safety that I'd rather not throw away, and if I can hide the complexity in the internals of the resource manager that'd be ok.