Emma, a very good point to address.
The xowiki support procs track the order of definitions (for javascript header information), and it "works" quite well.
However, i think that dave's suggestion of a priority is better since the order of definitions depends otherwise on the order of tcl/adp evaluation (might be tricky to get stuff to the top) and it allows to distinguish between cases where one does not care from the one were order is important. The definition order approach is good enough for xowiki and was defined there out of a need. But actually, order matters always, the framework should address the general cases.
In general the order is a partial order which is a lattice of dependencies. Therefore it would be best to define dependencies between css files (and javascript definitions). One should be able to say, that one set of definitions refines some other definitions (e.g. my-lists.css refines lists.css). Making these dependencies explicit might be some work, but improves maintainability.
In addition to dependencies, one should follow the performance rules for css and js (http://developer.yahoo.com/performance/rules.html#css_top) wherever possible.
My preferred approach would be to define ids for these definition files and use these to defines dependencies, like in
template::css_file lists \
-href /resources/acs-templating/lists.css \
-media all -title ... -alternate ...
template::css_file my_lists \
-refines lists \
-href /resources/my-pkg/my-lists.css ...
i would personally implement this in xotcl, where these files are xotcl objects having names which can be used as IDs. There it is easy to add additional attributes/methods, where the ordering could be calculated on a common superclass, etc., but that's another story.
