A few more points:

Instead of linear CSR expansion 4-8-? CSRs, should the mechanism provide for a future transition to an indirect state space?  That would need perhaps just two registers for address and data.  I acknowledge the value of the direct state, but I think it would be better to explicitly reject using such a scheme at this point (or reserving encoding space for moving to it).

It would be good to explicitly state whether or not these registers can be used for discovery or must not.  If not for discovery, then bits are Reserved and must not be set by SW that doesn't already know that an extension exists or perhaps doesn't know that the implementation implements that extension.  If for discovery, then individual extensions and implementations need to behave in a "safe" manner when bits are toggled blindly.

I think avoiding utility as discovery would be cleaner, as it reduces the number of redundant discovery mechanisms.  This is assuming that other methods for discovery exist.

It's natural to me that extensions that don't have state (instructions only) would want a similar mechanism to control extension enablement.  Paul Donahue brought this up earlier, but I saw no reaction.  Is this proposal limited to stateful extensions with the thought of some other mechanism for stateless ones?  Why would the architecture want a different mechanism, or should this mechanism be expanded to accommodate stateless extensions (mextenN?). 

The field consumption will happen a bit faster due to provisional allocation.  Many nascent or stalled extension proposals may be allocated a field provisionally, then enter purgatory or be retracted, meanwhile other extensions will overtake and allocate further fields, causing "holes", which may be impossible to deallocate if provisional extensions are out in the field.  I could imagine having a separate allocation scheme for provisionals, which then get a different permanent allocation as part of ratification.  Or we move to an indirect scheme where the state space is "free".  Or perhaps this isn't a real problem?

-Josh