Ohh, you're getting me started on that one now. It's really a mast-bait.. ;) Anyways, here it goes:
I'm of quite the opposite opinion regarding that.
Prime example: Thread and Thread.Thread. Thread is the module for all things thread related, while Thread.Thread is for actual thread instances. These two things are really very different, and they contain entirely different stuff. E.g:
o A thread related thing: A mutex, not related to any specific thread: Thread.Mutex o A thread instance related thing: The thread identifying number: Thread.Thread()->id_number().
So why try to coerce these two things into the same namespace? What's the beauty in that? I think it's prettier when different things actually have different names too. So even if Pike had proper static class members, I'd strongly vote for having different names in cases like this.
One case is for the sake of inherits: It makes perfect sense to inherit the instance class without inheriting the module, and in many cases it also makes sense to inherit the module without inheriting the instance class. Not that I can come up with a good reason to inherit the Thread module, but e.g. inheriting a parser module for some language to make another one for a language derivate doesn't seem far fetched.
Another (closely related) case is typing: Obviously a class attempting to behave like a thread instance shouldn't need to contain mutexes and stuff to fulfill the Thread module too. Dreadful kludgery is necessary to coerce the type system to accept this - just take a peek in Thread.pmod where an attempt has been done.
Given the simple principle that different things should have different names, it's actually not the case that Thread.Thread and Standards.URI.URI are silly looking and only makes sense if internals are considered. I can hardly think of more natural names, in fact. The closest could perhaps be Thread.Instance and Standards.URI.Instance, or the other way around Threading.Thread and, uhh, Standards.URIStandard.URI? Standards.URIStuff.URI? Nope, can't come up with anything there.
It's probably the repetition that bothers most people who think Thread.Thread looks ugly or even badly designed. Let's draw a parallell to Stdio.File: It's also a class for the principal object in a module that contains the related stuff. In that regard it doesn't seem far fetched that the module could have been called "File" instead of "Stdio". If it were, I bet there would have been opinions about joining File and File.File. But now the names happen to be different, and at least I haven't heard of anyone wanting to make Stdio.File() into Stdio().
As for having a `() in the module as an alias for create() in the instance class, that doesn't do much harm. I wouldn't regard it as particularly good either - it would obfuscate the code just to save a bit of space. Using the module name as an alias for the instance class type is otoh very messy indeed.