Some comments on this proposal: 1. Ought this proposal to be a CDR? At present #+(not cdr-42) ...doesn't necessarily tell us anything - it could just mean that your proposal hasn't been adopted. But suppose this proposal is CDR number 5 (as of 2007-08-24 this is the next in the sequence) and so requires the feature keyword :cdr-5. Then #+(and cdr-5 (not cdr-42)) ...implies that your proposal is in effect and therefore that the absense of :cdr-42 on *features* means that this implementation isn't conforming to CDR-42. 2. Names beginning with "CDR-" You suggest: programmers are discouraged from adding keyword symbols to *FEATURES* whose names begin with "CDR-" except as part of implementations of interfaces described in CDR documents. Given that you only specify use of keywords beginning with CDR-<nn>, I'm curious to know why you restricted keyword use to anything beginning with CDR-. Grasping at straws, I wonder whether the implementors of a lisp which employed cdr-consing would want to announce this to their users by means of the :CDR-CONS feature (the presence of which would conflict with your suggestion). 3. Read-time conditionals only? You haven't proposed a means of determining after read-time (for example: during load of a pre-compiled system, or at runtime) which CDRs are in effect. I think this weakens your proposal. On the other hand, the solution (defun featurep) is fairly clear and has previously been documented "elsewhere": http://clrfi.alu.org/clrfi/clrfi-1-featurep Should this be revisited and proposed as a CDR? 4. Minor typo I don't know about your reader,, but mine really enjoys complaining about "too many commas". (See under "Esthetics") - nick