Or Network.Protocol.Tcp.Server.Http? Or perhaps Protocol.Network.Tcp.Http.Server? ;)

The argument I was trying to make is for some sub-module hierarchies (e.g. HTTP) the word "network" communicates very little information and is thus superfluous. Also the deeper we make the hierarchy the more difficult it is to navigate it. Where would you expect to find a HTTP server module?

Network.Protocol
Network.Web
Network.Asynchronous

Here are three possible "answers":

Network.Protocol.Http.Server  -- How is a server a protocol?
Network.Web.Server  -- HTTP is a protocol that doesn't necessarily imply "web".
Network.Asynchronous  -- This is an implementation detail.

Or even worse, an HTTP server might not live in any one module making it difficult to find all the pieces you need for your current *task*.

Data.Http.Server.State
Control.Server  -- runServer
Network.Protocol.Http  -- sendResponse

I'm not convinced programmers think in these hierarchical terms at all when programming. More likely the thinking is task based than anything (although I need to find some evidence to support this view).

Also consider how many tokens you need to read when scanning e.g. an import list to find the relevant parts:

Network.X.Y.Server
Network.X.Z.Uri
etc

Furthermore, if to module imports always co-occur I think the module probably would have made more sense as one module unless 1) that would result in one huge modules or 2) that is not possible because of name clashes.