Let's just say I wholeheartedly agree with what you say and the approach of taking what exists in .LRN and make it available in OpenACS Proper seems like a good way to go. This would mean (though) in my opinion that the portal layouts configuration should be part of new-portal, though we should define the CSS in the master template of the theme. This would mean a theme contains all the information, including the portal one, but the functionality for portals and changing themes on portals is not part of acs-subsite (which is the place to choose the theme from).
It is important (in my opinion) that you are able to provide a full path to a theme. I am not sure we should make each theme a new package as we do at the moment. Maybe we could have a themes package which becomes a placeholder for all the themes that people provide back to OpenACS? As long as you can specify the theme by full path, that should be fine.
How does this effect the whole discussion how many masters we need and where to get them from? I think we should solve this in one go. While at it, a theme should also support the default list and form templates. I know that you should not have to use them anymore and default to CSS, but unless there is some guidelines which explain how to do that, most users might shy away from the exercise.
Would themes also take into account the group-master in the sense that using group-master is a theme? Or is a theme one level above, therefore, if you use group-master, dotlrn-master or default-master does not matter, the theme deals with the colors, layouts and such things irrespectively of the underlying master?
