The problem isn't the concept of namespaces but solving the very problems being raised in this thread. I've already called this out before. Most of these concerns were included in Child Thread: Survey of registry namespace designs for Cargo and Crates.io which I was expecting your reply to cover.
I'd also recommend posting relevant content on the relevant threads from that previous summary and focus your points on your incremental differences so people can more easily identify and talk to what is new you are bringing to the table rather than having to sift it out of long, detailed posts. Even knowing content is present in your post, it is hard to find.
Dismissing it as "small" I think says more about you then the problem.
Being "optional" is an escape hatch proportionate with the expected value. We would be rolling out a major feature to address a problem but those without a domain name would not be able to participate.
Relying on hosting services has a couple of problems (1) those domains are mutable because orgs / usernames are mutable and (2) migrating hosting services is a breaking change.
While I am for small, incremental RFCs, we need to consider what behavior we will cause with our actions and if that is right. If our answer is to push people to github.io and that is an option with significant problems, then we need to take ownership of that and ensure there is a viable option with a paved path.
Yes, they are seemingly in conflict with each other. Calling it unreasonable is not accurate and is like saying "memory safety without garbage collection" is unreasonable. We shouldn't shy away from solving apparent contradictions.
As I discussed at Child Thread: Survey of registry namespace designs for Cargo and Crates.io , there may be ways to solve the transfer / rename case. Or maybe we see a strong justification for why we should flex on one of these. Or maybe we go with a completely different solution, like organizational tags, that cover most of the use cases without stepping into this quagmire.