Folks -

I'm working slowly through some of the traits test cases, and some of 
them simply make no sense to me. Currently, I'm in 
TraitCompositionTest>>testInvalidComposition and most of it seems very 
odd, for example:

	self should: [self t1 @ { (#a -> #b) } @ { (#x -> #y) }]
		raise: TraitCompositionException.

This currently signals a TraitCompositionException 'Invalid trait 
exclusion. Aliases have to be specified before exclusions.' but note 
that the above doesn't *have* any exclusions, so what's the point here? 
 From my understanding of traits, I would rather assume that:

	self assert: (self t1 @ { (#a -> #b) } @ { (#x -> #y) })
		= (self t1 @ {#a -> #b. #x -> #y}).

Same goes for exclusions, e.g., instead of:

	self should: [self t1 - { #a } - { #b }] raise: TraitCompositionException.

I would rather claim that:

	self assert: (self t1 - {#a} - {#b}) = (self t1 - {#a. #b}).

Lastly, it's not clear to me why the requirement that aliases have to be 
specified before exclusions even exists. It seems pretty clear what the 
expected outcome is. Or is this just to keep a bit of conceptual 
clarity, i.e., that aliasing (@ operator) comes always before exclusions 
(- operator). From the implementation point of view it's actually 
simpler to support arbitrary compositions and if you're into this kind 
of stuff I see no reason to force superficial rules on you :-)

Oh, and one more issue: I'm starting to question the idea that 
"conflicting" trait methods should create a trait conflict. It seems to 
me that "last one wins" would be more useful, i.e., if you have two 
traits t1 and t2 and use them via t1+t2 you get t2's version; if you use 
them via t2+t1 you get t1's version. You're always free to override the 
version if you don't like the result but I think that "last one wins" 
will be a useful outcome in more cases than raising an error :-)

Any comments are greatly welcome.

Cheers,
   - Andreas