Ohh, you're getting me started on that one now. It's really a mast-bait.. ;) Anyways, here it goes:
I know. :-) But it's an interesting subject. I just found that I share most of your ideas were the names just picked as collective nouns for the module and singular nouns for classes. (Which would translate to "Threads.Thread" in the specific case of "Thread.Thread".) A bit like the Files.File name of ancient ages, I suppose. On the other hand, I'm not sure I'd like Threads.Mutex, though probably mostly for being used to the name it has now, and that naming policy becomes absurd for GTK, GL and similar modules.
You are right on target about the repetition being the sole source of aesthetic mutterings -- in Stdio.File, I don't think anybody finds it the least bit unpleasant.
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.
I suppose that mostly moves the issue from instantiation to the type, yes (assuming you meant having a Standard.URI.URI that also could be created via Standard.URI.`()).
We seem to agree about joining the module and class namespace to one is bad, both for types and inheritance. I just wish we'd come up with some nice way of attaching methods and constants to a class name (i e Standards.URI.encode()) without messing with the looks of its object instances (Standards.URI()->encode) by necessity.