Ao lado de ncoghlan, sou o outro mantenedor do sistema de importação do Python e o autor de sua implementação atual, importlib (http://docs.python.org/dev/py3k/library/importlib.html). Tudo o que Nick disse que eu concordo, então eu só quero adicionar algumas informações extras.
Primeiro, não confie muito no PEP 302 diretamente, mas observe o que o importlib fornece em termos de classes base abstratas etc. Para compatibilidade com versões anteriores, as coisas tinham que ser compatíveis com o PEP 302, mas eu tinha que adicionar algumas das minhas próprias APIs para finalizar o suporte à verdadeira flexibilidade.
Outro ponto importante é que você está dando aos desenvolvedores duas partes de flexibilidade. Uma é a capacidade de armazenar código de uma maneira que não seja apenas diretamente no sistema de arquivos como arquivos individuais (eu chamo isso de backend de armazenamento para importações), por exemplo, isso permite que o código viva em um arquivo zip, banco de dados sqlite, etc. O outro suporte é permitir que o controle pré ou pós-processe o código de alguma maneira, por exemplo, Quixote (https://www.mems-exchange.org/software/quixote/) e seu uso alternativo de literais de string não atribuídos a uma variável seria muito mais fácil de suportar.
Enquanto o último raramente é necessário, o primeiro é onde você precisa se preocupar com o suporte. E é aí que você acaba redefinindo praticamente as APIs de interação do sistema de arquivos. Como algumas pessoas precisam de ativos armazenados como arquivos com seu código, é necessário fornecer uma boa maneira de ler arquivos, descobrir arquivos etc. Ainda precisamos implementar a parte da API para descobrir quais arquivos de dados estão disponíveis, listá-los etc. .
Mas você também precisa de APIs específicas do código. Como Nick mencionou, você acaba precisando de APIs para descobrir quais módulos um pacote contém etc. que não são específicos de arquivos. Existe essa estranha dualidade de ter APIs para lidar com módulos nos quais você extraiu o conceito de arquivos, mas acaba precisando fornecer APIs para acessar dados de ativos semelhantes a arquivos. E assim que você tenta implementar uma em relação à outra para evitar duplicação, as águas ficam realmente escuras (ou seja, as pessoas acabam confiando na estrutura esperada do caminho do arquivo etc.) sem prestar atenção ao fato de que o caminho pode não ser um caminho verdadeiro porque é para um arquivo zip que contém código e não apenas um arquivo). IOW, você precisará implementar duas APIs semelhantes, mas será melhor a longo prazo.
Como Nick disse, nossa solução é um bom ponto de partida, mas não é assim que eu faria hoje se estivesse projetando a API do zero.