Sou o mantenedor do módulo runpy do Python e um dos mantenedores do atual sistema de importação. Embora o nosso sistema de importação seja impressionantemente flexível, aconselho que não o adote por atacado sem fazer alguns ajustes - devido a preocupações com a compatibilidade retroativa, há muitas coisas que são mais difíceis do que seriam necessárias de outra forma.
Uma coisa que prejudica o PEP 302 no Python é o tempo que levamos para converter o sistema de importação principal para usá-lo. Na maior parte de uma década, qualquer um que fizesse algo complexo com ganchos de importação estava preso implementando duas partes: uma gerenciando carregadores compatíveis com PEP 302 (como importações de zip) e uma segunda manipulando o mecanismo de importação baseado no sistema de arquivos padrão. É somente no próximo 3.3 que o manuseio de carregadores PEP 302 também cuidará do manuseio de módulos importados através do mecanismo padrão de importação do sistema de arquivos. Tente não repetir esse erro se puder evitá-lo.
O PEP 420 (implementado para o Python 3.3) faz algumas adições ao protocolo para permitir que os importadores contribuam com partes dos pacotes de namespaces. Ele também corrige um problema de nomenclatura na definição da API do Finder (efetivamente substituindo o "find_module" com o nome "find_loader" mais preciso). Isso deve ser documentado com mais clareza na especificação de idioma no momento em que o 3.3rc1 ocorrer em algumas semanas.
Outro problema notável é que a abordagem documentada especificamente no PEP 302 tem um estado global de processo excessivo. Não siga-nos nesse caminho - tente encapsular o estado em um modelo de objeto mais coerente, então é um pouco mais fácil importar seletivamente outros módulos (módulos de extensão C são a ruína de tornar qualquer encapsulamento completamente eficaz, mas até mesmo algum nível de encapsulamento pode ser útil).
O PEP 406 (http://www.python.org/dev/peps/pep-0406/) discute uma possível evolução compatível da abordagem do Python com encapsulamento de estado aprimorado. No entanto, se você tiver um modelo de estado encapsulado desde o início, poderá definir suas APIs de acordo e evitar que importadores e carregadores acessem o estado global (em vez disso, passar uma referência para o mecanismo ativo).
Outra peça que faltava no PEP 302 é a capacidade de perguntar a um importador por um iterador sobre os módulos fornecidos por esse importador (isso é necessário para coisas como utilitários de congelamento e utilitários de documentação automática que extraem doctrings). Como é incrivelmente útil, você provavelmente seria melhor padronizá-lo desde o início: link (nós provavelmente vamos finalmente elevar isso para uma API formalmente especificada no Python 3.4)
E meu último comentário é que você deve dar uma olhada na divisão de responsabilidades entre o sistema de importação e os objetos do carregador. Em particular, considere dividir a API "load_module" em etapas "init_module" e "exec_module" separadas. Isso deve permitir que você minimize o grau em que os carregadores precisam interagir diretamente com o estado de importação.
O PEP 302 e o importlib são um ótimo ponto de partida para um sistema de importação mais flexível, mas definitivamente existem erros que cometemos e que vale a pena evitar.