Eric and I discussed this further this morning. We were interested in two main points:
1. When no custom namespace is used, we definitely shouldn't double the storage requirements for the class object
2. If a custom namespace is used, it would be nice to make it available to both the __init_class__ hook *and* to class decorators

The design we came up with for doing so is for type.__new__ to include the equivalent of:

    if type(namespace) != dict:
        cls.__namespace__ = types.MappingProxyType(namespace)

The practical downside of that approach is that it still doubles the storage requirements for every class that uses a custom namespace, even if the custom namespace isn't actually needed after creation. The upside is that you can write a class decorator that needs ordering information and say "to use this decorator, you must also specify 'namespace=collections.OrderedDict()'"

There's also a major complexity downside to that approach - the distinction between __dict__ and __namespace__ is somewhat subtle, especially since __namespace__ won't see later changes made through setattr() and delattr(), and __dict__ won't see changes made through any external references to the custom namespace.

That means my current inclination is to instead change the signature of __init_class__ to accept a read-only view of the execution namespace as a second parameter. Decorators won't have access to the details lost by the copying of attributes into an ordinary dict unless used with a metaclass or base class that takes steps to attach it to the created class object. I can live with that limitation, and it means we only have to properly document the "the contents of the class execution namespace are copied into an ordinary dict instance when the class is created" behaviour of type to explain why __init_class__ has the second parameter.