i think that you both don't hit the point. yes, qx, i agree 
that extending the vector type is not a good idea. but, if 
you remember, i first asked you about the existence of 
isAlias?() before i tried to derive a MultiVector (in face 
of not having a different solution.)

ksreeram, i guess that i can't show you a 'very practical 
and concrete' use case (to just fill a gap in the language)
because the types i'm talking about are generally 
understood as being patterns, and thus data, rather than 
types. in oo-languages they could be derived classes but 
that's a different point. the point is that i don't know 
how to use the powers of compile-time predicates on 
patterns.

patterns are no types in terms of programming languages 
though they are handled very similar - at runtime. think of
basic polygons for drawing or of basic text templates 
with placeholders for quick website creation. all these
'types' of patterns have one thing in common: they very 
often fit into a simple storage type, profit from its given
interface and only need a small selection of extra handlers.
only because they must be distinctable and configurable 
they are rather implemented as own types or as pure data 
accompanied with meta-data and stored in a struct. however, 
that's not the generic way.

in clay, i'd implement the pattern types and the 
configuration types separately because the configuration 
types (for color etc.) can also be used generically. the 
only left 'redundancy' is the identifier. that's the point. 
if i could turn that identifier into an alias and check for 
it with isAlias?(), the struct could be dropped, and 
overloading the storage-type interface would do the job -
at compile-time. this is the efficiency i want to gain from 
clay. otherwise i'm forced to create runtime overhead 
without a hard reason.

if you know a better way to reach this goal, i'm fully open.