1. schemaSpec/classRef[ starts-with( @key, 'model.') ]
This means (much like elementRef as a direct child of schemaSpec) "if you've got a definition for that class knocking around in your @source, we're going to use it"
Hmm. Guess that makes sense, if a bit dangerous in that it makes it more likely I include a reference to a model full of references to undefined elements. (E.g., by having <classRef key="model.personNamePart"/> without <moduleRef key="namesdates"/>.)
2. content/classRef[ starts-with( @key, 'att.') ]
This shouldn't happen. It is redundant with making the parent element a member of the class concerned.
3. content/descendent::classRef[ starts-with( @key, 'att.') ]
Same again.
In which case these should be addressed by (b), below.
4. classRef[ starts-with( @key, 'att.' ][ @expand ] )
See documentation for @expand
I did. Although it never mentions "element" (as opposed to "attribute"), it explicitly refers to the content model, which in your mind (as indicated by your response to my postscript and #2 & #3) should not contain references to attributes. That said, nothing at the moment prevents an ODD writer from putting <classRef key="att.handFeatures" expand="alternate"/> as a child of <schemaSpec>, and expect that through some magic only 1 of the hand feature attributes could be used on an element that included <memberOf key="att.handFeatures"/>. Not sure what a user who puts in <classRef key="att.handFeatures" expand="sequenceRepeatable"> thinks is going to happen, since attributes cannot have sequence and cannot be repeated, but she might believe they would all be required, I guess. So I'm inclined to think the documentation for @expand should be explicit (that it is for model classes, not attribute classes), and that a validation check (probably a Schematron rule) should warn you if you try to use @expand when key="att.*".
Stylesheets code that does the right thing is a wonderful concept, whose time has come.
Soon, I hope. I actually ran across this while researching Stylesheets tickets.