Keep these ideas distinct:

1. The Cardtype extension.  Each card will not necessarily have cardtype card directly associated with it because we can use patterns without referencing cardtype as an attribute or plus card to each card.  Patterns can be used to implement cardtype as an extension, and we will for continuity.
   As I see it, this one would probably come last.  -efm
   I'm fine with you ordering your priorities as you see fit.  It just looks to me like this extension doesn't do that much except map the cardtype to codename/supporting classes.  You might just move the codename into the card record.  Either way the important part is to keep the idea distinct from the rest.
   Oh, getting rid of the cardtype extension should be easy-- you're right -- and I think it should happen very soon.  But you're talking about representing types via patterns -- that's a lot harder.
   Sorry, I should be more clear.  If you made the extension go away, would you make it <card>+*type, or what?  You might turn it into a pointer card or just leave it in the card record and just pretend like it is a pointer card attached.  Initially, all cards have to have one, but that would be relaxed as patterns can specify the type.  Is that more or less how you are thinking?
2. Card classes.  We need to find an underlying class from name and type args, or similar, but there is no need for a 1-1 cardtype to card-class relationship.  Many cardtypes can share a class, or subclass and extend the same basic card class, and as in 1. the card may not have a cardtype, but it has to be mapped to a card class or fall back to a default class (Basic).
   These are just "patterns", right? 
   Right, this mapping would be defined by pattern based hooks.
   Are you using "card classes" to be something beyond just patterns?  Are these patterns that have associated code?
   Initially this might really just be one ruby class with overloads based on the initial cardtype set (i.e. current Wagn cardtypes plus a few new ones like patterns), but in principle I want to be able to have different card types have that are dependent on a loaded class module.  Patterns would be used to access card class based on the inputs, name, type, etc. (what is handled in with_class_from_args now).
3. Rendering, validation and view options can be modified by extending these card classes with pattern declarations that just customize the base and extended card classes internally.  In other words, modules can add new syntax/semantics to the DSLs referenced in pattern card definitions.  This sort of syntax can provide standard ways to declare new options for these phases of card processing.
   What do you mean by pattern card definitions?
   This is the out of band card stuff that defines the WADL relationships.  What I'm trying to say is that if you had a new card content handler, loading that module might add methods that extend the WADL definition DSLs thus adding whole new features or classes of content with very different view/render options (for example, multi-media content that you can "play, rewind, play from <time>" or other presentation actions).
4. Content-type.  A cardtype module can support any content coding it wants.  If the cardtype supports standard linking and transcusions, it needs to do that through the card api, and it needs to render in the client context for trascluded card.  The module needs to parse out the link and transclusion coding (i.e. what's inside the double [] and {} coding) and process them in standard way, but how it parses it out and the rendering actions, etc. are all defined in the module or the base it derives from.  That way you could code a relative trasclusion in XML contend like this: <org> ... <transclude>+search card|item:closed</transclude>, or put it in attributes, or similarly as Json.