Thanks for splitting these up @ofek!
I’d like to bring up a pure implementation (non-policy) point from the original thread around the idea of fixed prefixes (i.e., this comment).
In particular, I think this PEP should consider that approach and, if there’s consensus that it’s not a good idea, then it should be listed under “Rejected Ideas” with a rationale.
To summarize the idea again, for continuity: rather than allowing grants of any top-level prefix (such as foo-bar- or foo-), namespaces would instead be defined as grants within a fixed subset of well-known prefixes.
The names of these prefixes can be subject to debate (or logistical/index constraints), but the idea behind them would be to limit/reduce the ambiguity behind package names like foo-bar-baz, which in turn current proposal could be either bar-baz in namespace foo, baz in namespace foo-bar, or a normal package named foo-bar-baz.
Concretely, assuming a known prefix like corpspace- (picked blithely to demonstrate that the actual prefix doesn’t matter), grants could look something like this:
corpspace-foo:foois a corporate organization namespace forfoocorpspace-wing-ding:wing-dingis a similar corporate organization namespace
Similarly, there could be an orgspace- (again purely as an example) well-known prefix for non-corporate organizational namespaces allotments.
I think the two strongest arguments for this approach are that it’s (1) backwards compatible with the flat index like the current PEP is, and (2) avoids much of the ambiguity around how to interpret identifiers that may or may not have a namespace component in them.
At the same time, I think it’s been raised that companies may not like this naming scheme as much as having top-level prefixes (although it’s similar to the popular/mandatory RDN scheme in Java). However, my personal inclination is that the aesthetic value of corporate namespaces should be given relatively less priority versus efforts to generally reduce the ambiguity of Python packaging 
(I recognize that it’s poor form to repeatedly bring up an idea for consideration, so this will be my last time reintroducing it!)