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