Well, I think that keeping a nice, simple file storage package around for folks who just want a package that provides a nice, simple folder/file UI is important. When I talk about rewriting file storage my reasons are more due to the state of the datamodel (sucks) and code (much of which sucks) than a desire to get rid of this simple package in favor of something more complex.
No need to burden people with a complex UI if they don't need it.
It might be possible to graft on handling of sets of files like Carl's talking about to the file storage UI, so that's a possibilty, but it would probably be good to see a design in hand for people to comment on before deciding to do this (vs. have Heidelberg develop a new package to manage this type content)
The SCORM stuff seems much more complex, containing elements of a CMS beyond anything one would expect to see in a simple file storage package.
The SCORM folk have thus far been very good about sharing their design ideas and status of work. This is excellent. Ernie et al - feel free to ask questions about whether or not existing CR or CMS code can handle tasks you might need to complete when implementing your SCORM package. There's a lot of hidden functionality there.
By coincidence those of us on the TAB probably have as much knowledge as anyone about what's there (when we pool our knowledge, that is.) Dan Wickstorm did the original port, Jeff Davis is using some of the fancy features (registering templates to content types and items, etc), and Lars and I have each spent time digging through the code in efforts to understand exactly what's there in terms of functionality.
Of course, Tils, who is working with you, has already implemented a significant set of CR-based packages for Greenpeace DE so also has a lot of knowledge ...
