first of all, sorry by my laggy answer but, two days ago, my eMac logic board died and I've spent these days copying everything from its disk to my laptop, firewire disk and CDs. Now the eMac is "knowing the World", traveling to Apple to be repaired. Hope it will be back at home soon!
About these (really old
With some exceptions (see below) I think that it should be really easy to implement at restore time, basically because the restore code in each module currently is executed for each activity, so calling it with only certain activities (pre-selected in a previous xml parse) shouldn't be difficult at all.
What is more complicated (due to its current implementation) is to allow such selection of activities at backup time. Currently I export all the module DB data per activity (cool!), but the moddata/module dir is copied completelly (bad!). Because of this, we should modify every module backup to copy moddata files selectively (by activity). Then we could implement the selective backup.
And the point I haven't been able to resolve is "how I backup (and restore) an uploaded resource?". As these type of resources are absolutely free (you can place them where you want and having every structure for images, scripts...), I haven't idea about how to deal with them! Perhaps we should build some type of html parser to be able to select what to copy (links, images, styles...) but it's really out of my skills and probably, out of the backup objetives. Although such type of parser will allow us to export/import resources in other formats (IMS, SCORM....) in the future!
Other details must be modified too to allow individual selection of activities to work at backup time, but I think they are relatively easy (computable) and I don't specify them here.
After all this, I think that, perhaps, it could be nice to implement the restore first as it sould be easier. The code should work for near every module but the uploaded-resource (and other "free-storage" modules). We could implement it module by module, adding an "restore_individual_XXX" function. In practically all the modules, it will call the standard "restore_XXX" function but we could use it to decide when to allow or no the individual selection in a module.
Having this working will allow moodlers to avoid the "double" backup/restore process and selectively load activities in their courses what is a long awaited feature. Then, if required, we could start with the backup part of the functionality.
That's my view of the problem and a possible roadmap to do it...when in Moodle's timeframe it will fit...uhm, difficult for now (for me).
Ciao