Please note that I've moved this thread to the Categorization Project forum because it's now drifting towards general categorization issues.

I think the way to go here is to enable browsing of intersections of categories: if you're interested in Aristotle on Ethics, you browse the intersection of the Aristotle and Ethics categories, that is, the works that are classified under both categories. Creating actual in-database categories for all intersections of two categories would swamp the system, and manually adding works in these intersection categories would not be manageable. We're much better off taking advantage of the fact that we can infer membership in virtual intersection categories from membership in the basic categories. 
The challenge here is to implement this in a way that is intuitive for the end user and computationally manageable. One possibility to keep things simple is to limit intersections to pairs of categories involving one area-level cat. So you could browse Aristotle and Meta-Ethics but not Aristotle and the Problem of Evil. I don't know if that would be fine-grained enough. Since there are about 30 categories and 3000 items under Aristotle, on average each such intersections with Aristotle should have about 100 items, but there could be huge variations. 

Limiting intersections to areas would have the advantage that we could provide a drop-down box of intersection options or an expanded list to pick from. If we allow all combinations, we have the usual problem that the full list of categories is unmanageably big. We are pretty much limited to providing a search box like in the category finder. Sometimes its hard for people to find what they are looking for in this way. Another option is to provide a dropdown of areas and a searchbox for other cats. This is probably the best on reflection.

In any case, the widget to create an intersection should probably be located within the 'Related categories' section just below category headers. This would further strain this label, but the option has to be prominent and we probably need more than a single line. The alternative is to put it next to the 'search inside' feature, which constraints us to a line of text. 

The implementation of a single intersection (as opposed to arbitrarily long intersections) should be easy and efficient. We could also allow 3-cat combinations. But I wouldn't want to do arbitrary combinations because that's useless and would really complicate things under the hood.