Hmm, I'm not clear on what functionality ResourceLoader and ResourceCache will serve.
[/quote]
ResourceLoader -> loads resources
ResourceCache -> caches resoures

Could you maybe give and example of how it would be used?
[/quote]
A simple example would be:

#include <map>
#include <string>
#include <memory>
#include <iostream>

// Simple file name based resource loader.
template<typename T>
class ResourceLoader
{
public:
ResourceLoader(const std::string &basePath)
:
basePath(basePath)
{
}

std::shared_ptr<T> load(const std::string &name)
{
return std::make_shared<T>(basePath + name);
}

private:
std::string basePath;
};

template<typename T>
class ResourceCache
{
typedef std::shared_ptr<T> ResourcePtr;
typedef std::map<std::string, ResourcePtr> ResourceMap;
public:
ResourceCache(ResourceLoader<T> *loader)
:
loader(loader)
{
}

ResourcePtr get(const std::string &name)
{
ResourceMap::iterator i = map.find(name);
if(i != map.end())
{
return i->second;
}
ResourcePtr resource = loader->load(name);
map.insert(std::make_pair(name, resource));
return resource;
}

private:
ResourceMap map;
ResourceLoader<T> *loader
};

class Example
{
public:
Example(const std::string &path)
:
path(path)
{
std::cout << "Example resource construction: " << path << '\n';
}

void print()
{
std::cout << "Example resource use " << path << '\n';
}

private:
std::string path;
};

int main()
{
ResourceLoader<Example> loader("resources/examples/");
ResourceCache<Example> cache(&loader);

std::shared_ptr<Example> example;

example = cache.get("hello.example");
example->print();

example = cache.get("goodbye.example");
example->print();

example = cache.get("hello.example");
example->print();
}

Asynchronous loading can be achieved by having some kind of "Future" resource. That is, these resources would either block on first use (bad - might as well use synchronous loading) or be no-ops until loaded (e.g. use a transparent 1x1 texture until the actual texture is fully ready, a silent sound, an empty mesh). The other alternative is to have your resource loader return a third state (instead of NULL/exception and Resource, it can return "pending"). The game logic keeps trying to load the resource until it gets a non-pending result.

The main problem with the asynchronous loading is where do you want to deal with it. My former proposal forces the logic into the loadee, the client code gets a proxy it can use immediately, whereas the latter proposal puts the burden on the client logic but makes the resource implementation simpler.

What kind of game are you writing? Try to keep your resource management code in line with the scope of the game. Not every game needs asynchronous loading, and simpler games might benefit from a greedy approach of simply loading all the resources in a particular directory tree once at startup, if memory allows.

rip-off : What is the purpose of ResourceLoader, if all it does is construct a new T using T's constructor?
[/quote]
It is a separation of concerns, I don't think a cache should be responsible for creating the objects it is caching. Its job is to act as a buffer between the client and the "expensive operation", whatever that happens to be.

The resource loader could do other things, it could do the procedural generation, or load from an archive. Perhaps it needs to be like a factory, e.g. the texture needs to be created in by a particular Renderer instance. Or maybe the resources don't do I/O themselves, they expect to be constructed with in-memory data - the loader would do the I/O and pass the byte buffer to the Resource constuctor.

I gave my example one a "basePath", which was supposed to hint at this idea. Maybe I didn't make it clear enough. But it doesn't just create a new T, simple as it is.

I also have to take into account resources that don't come from disk. Procedural textures and render-to-textures, as haegar mentioned. I would also like to incorporate the ability for resources loaded from files to automatically reload themselves if they receive a notification from the file system that the file has been modified.
[/quote]
A proxy can do all of these things. Monitoring for changes is similar to asynchronous loading, your proxy keeps rendering with the old value until the new values is created, then it can just change which value is bound. Procedural generation can be handled similarly, conceptually it is no different from asynchronous loading from disk.

For Render-To-Texture, you might add a function to the cache so that you can add a named object to it, if you want to cache such textures. If not - then it isn't really a concern of your loading/caching infrastructure, it is something else.

The main point really isn't to give you some concrete design saying "this is the interface for managing assets", but rather to show that if you split the functionality into a number of distinct classes with well designed responsibilities it makes the code easier to manage. I mean, if you look at the resource cache code I gave you can see that it doesn't contain any bugs (apart from not maintaining an invariant that the loader is not-null). If the code for the caching, creating, procedural generation, background loading, swapping default/updated resources as I/O completes were all in one monolithic "ResourceManager" class then I think it would be much less clear what is going on.

You were looking for an interface for such a class, all that I am suggesting is breaking the "management" of resources into distinct sub units of functionality. These may interact, but at least each sub-unit has a reasonably well defined scope of operations.