It could download dependencies, yes. But I kind of think that should be the job of a dedicated game manager--the plugins are dependencies of games, or of another plugin, or are explicitly installed. Like how packages and groups work for package managers like Yum, Pacman, and Aptitude. But in the end, I don't download libpng because I love having libpng, I download it so that programs can read png images. I think it should be game-centric. I just might be working on a way for games to specify what plugins they really need, too...
On the other hand, it may be good to have a utility like this to handle plugin dependencies. The game manager could be engine-independent, and then tell the configuration utility what it is doing. The config utility could then, say, change settings for the game to handle, for instance, engine differences (like TurboSphere using constructors instead of functions for engine objects by including additional scripts, or the opposite for a game designed for TurboSphere but being run in another engine), download plugins if necessary, etc.
It would be cool to have the plugins' function and variable lists act as a sort of 'provides' list (like in Yum), so you could use alternative plugins if you wanted, or if you already had a plugin that provided the functions you wanted installed but the game specified a different plugin by default you could just use the plugin you already have.
But that's a ways off. Once one of the Sphere Next Generation engines is done, I may just look into this kind of utility to make it easier to use any of the engines you want. Of course, that would mean all the engine devs would have to come together and agree on standards for these things...or one of us could just blaze forward, and the others would be inclined to adopt it. I wouldn't mind that, I don't especially like creating standards myself.
After all this work with T5, I looked at some of the code that is in the engine's support libraries. And I don't like what I see! It's some of the first C++ I ever wrote, and the quality and methods are about what you'd expect given that. The configmanager needs serious work (not that it doesn't work, it's just not pretty, clean, or particularly logical), and I need to finally put all the graphical algorithms inside graphicalg. That's what its' there for!
I know the interface isn't too nice right now...but that doesn't cause it to segfault, (whereas opening a file with T5 before calling T5_Init does, for example), so I haven't done much for it yet