I think this was based on the assumption that *existing* namespace package approaches would break under the new scheme. Since that is not the case, I suspect those previous objections were overstated (and all packaging related code manages to cope well enough with modules where the file name doesn't match the package name)
I just drafted a message rebutting Phillip's objection, when I then found that you disagree as well :-) One elaboration:
The downsides, however, are also plentiful. If a package starts its life as a normal package, it must be renamed when it becomes a namespace, with the implied consequences for revision control tools.
If a package starts out as a regular (P/__init__.py) package (possibly with __init__.py being empty), then making it a namespace package actually requires no change at all - that single __init__.py could continue to exist. Developers may decide to still delete __init__.py and rename the package to .pyp (with VCS consequences), but that would be their choice deciding whether purity beats practicality in their case (where I think most developers actually would rename the directory once they can drop support for pre-3.3 releases). Regards, Martin