Drupal CRM's architecture - clarifications and further steps

There's a wiki page about the CRM stack, and I thought it would be valuable to move discussion and clarification here.

I've tried to construct mental maps of the existing specification, to make sure that it's not inconsistent or ambiguous. I've attached the results of a couple of these mental maps below. I don't want to re-hash existing discussions, or insert my own opinions into them in retrospect, but I do want to make sure that the spec has correctly encapsulated the original intention! That way we can develop more closely to an agreed spec and avoid developing something which works but isn't what was expected.

I'll explain how I think it's all meant to happen below. If anyone has access to a brilliant primer on D7 Field API terminology for dummies then do let me know, as I'm currently mired in D6 terminology myself.

Page 1: genera

Please tell me what's wrong with this statement, as encapsulated in the attachment:

A genus is a mixable class (D7: "bundle"?), which can be applied to an existing profile object (D7: "entity"?) and leave the object with extra field instances (D7?). It does not affect the underlying profile type bundle (D7?) The genus does not get applied across all profile objects (D7?) of a particular type, just one particular party's particular profile. Genera are additive: that is, applying two genera leads to the profile instance having the union of the field instances described by the fields on each genus.

More specifically:

1. Should a genus apply fields to the profile "content type" (D7: "bundle"?) or just to the specific profile object (D7: "entity"?)
2. Can a genus apply fields across several profiles or profile types, saying "I want fields X and Y on the personal information profile, but fields A and B on the membership profile"?
3. Are some genera mutually incompatible?

Page 2: parties and users

Again, tell me what's wrong with this statement:

A party is an object (D7: "entity"?) of only one type (so not "content-typed" - D7?) which can have profiles attached to it via a standard entity-entity reference (D7?) The party behaves exactly like a user. If a user exists, the party is replaced by the user--profile core of Profile2 takes over. Users can have typed relations to parties which carry permissions, so a given user can

Again, more specifically:

1. Party--party or party--user typed relationships - it strikes me that parties behave a lot like organic groups. You can belong to them if they're organizations, for example. This would be very similar to a low-end CRM solution we recently had to employ with a client, whereby organic groups were indeed used to represent businesses in a directory. Does it make sense to bring D7 Groups into the tech stack?
2. Should the party be there instead of a user, or along with it? That is, should the profile_anonymous module only add parties for non-user profile collections, or when enabled should it transplant a party into every existing user--profile relationship, so that you get a nicer symmetry of (optional user)--party--profiles? That transplanting would also help with party--other-user relationships, because there'll always be a party object to treat as an organic group and assign typed relationships to. Basically, you'd always be able to find a party object in a profile collection: the user would end up along for the ride.

Other clarifications

1. Is it worth clarifying what's in the stack - the code architecture - and what's part of the model description - the data architecture?