I do not know of an article that describes your concerns.

I am working on a namespace standard at the moment for Microsoft IT to use
internally, so that we may get some better consistency.  In my case, I've
spoken with dozens of developers in different IT teams, and in each case,
they are largely sticking to a namespace structure that is much flatter than
you are implying.  Namespaces aren't being used to differentiate to the
detail that you are suggesting.

I would suggest that you consider that your class library is specific to a
particular application that is tied to a specific business process within
your company.  In that sense, the namespace should be
ACME.Area.Process.Application where 'Area' is the functional area of your
user's business process (Finance, Marketing, CustomerService, Product,
Partner, etc) and 'Process' is the business process that your application
supports (for example, for financial operations, you may have something like
'Invoice', 'Portal', or 'Reconciliation').  Application would be the
namespace of the application itself.  Within MS, this is usually some
unrelated name or acronym... like Longhorn or Whitehorse (only the IT folks
can get pretty creative :-).

Using multiple namespaces within an application is done, but somewhat
sparingly.  One fairly complex application I worked on had three namespaces:
one root and two child, for 400+ classes.  For the most part, a namespace
tied directly to an assembly.  In other words, all of the classes in that
namespace were contained in that assembly.  (in the aforementioned app,
there were three assemblies).

So, the best advice I can come up with: if you are creating one assembly,
create one namespace.