Well... - I think, the underlying concept is easy; we do this all the time on an everyday basis. "This Brunello is wonderful, but it's to expensive for me." - So obviously there are pricing levels as well as quality aspects to consider:
Generalization Set Price_Level { Expensive_Wine, Cheap_Wine }
Generalization Set Wine_Quality { Wonderful_Wine, Awful_Wine }
I think, multiple inheritance is indispensible in models dealing with semantics. And it might be practical for analytic models, even if you do have to resolve the multi-hierarchy into a mono-hierarchy during design. A matter of taste, I guess. It resembles de-normalization: After having normalized everthing by the book, you decide which tables you actually do need (and how many you can afford in terms of performane etc.).
I, for my part, do not really see the necessity to distinguish between powertype and generalization set. Outside UML (and programming), the terms "class" and "set" are often used more or less synonymously (not counting stuff like "ultimate classes"). Inside UML, a class isn't a set, but a descriptor for a set (outside: a UML::Class would be a specification of the class or set). So if sets go by their classes in UML - why suddenly use the set (generalization set) and the class (powertype) instead of just assigning a powertype?
Thanks again, M.