That article has two subtly different general recommendations:
1) "Only applications should have Composition Roots. Libraries and frameworks shouldn't."
2) "A DI Container should only be referenced from the Composition Root. All other modules should have no reference to the container."
You said:
It seems that to do this correctly, the client app needs to be aware of all the implementation crud and its up to the client to compose everything via a Composition Root.
Now, I know that one of the issues here is that it looks like the (human) users of your library must know about and understand C in order to use B. That's not necessarily the case. But let me digress a bit, just so that we're on the same page when it comes to DI.
Think about the client application and the Composition Root as two separate components (even though they may reside in the same module/package/library), and design them like that. The Composition Root references (knows about) everything that is being composed (actually, that very fact significantly contributes to the decoupling of other components). It is intended to be the single place where the entire application is composed. The core application itself doesn't need to know anything about C, because C will be injected into B by the Composition Root. That looks something like this (some arrows are omitted - the CR knows about the interfaces as well):
Note that B and C are decoupled in the sense that C is (in this particular design) swappable. Having the application's Composition Root compose B and C is more flexible, as it lets clients easily swap C for a different implementation (perhaps even one developed by a 3rd party). It also lets you test each of these components in isolation. Now, sometimes it may be the case that C is really not that useful on it's own, and that may render these considerations somewhat less relevant.
1) "Only applications should have Composition Roots. Libraries and frameworks shouldn't."
I think this statement is motivated, at least in part, by what I described above.
But, in another article, he writes about how to design a DI-friendly library; there's a section named "Consider a Facade":
If some objects are difficult to construct, because their classes have
complex constructors, consider supplying a Facade with a good default
combination of appropriate dependencies.
In your case, this fits nicely with the idea that clients of B shouldn't have to know about or understand C in order to get started. So having a convenience Facade lets you be both flexible and have one or more preconfigured defaults (in your case, there's only one option at the moment). Note that this Facade, as described in the article, actually composes the components of the library in the style of what Seemann calls Pure DI, so you could argue that it's a local composition root, but it looks like he does not consider this to be the Composition Root pattern.
It looks like it's a conceptual thing; I'm guessing now, but it seems to me that his definition of Composition Root is that it's a dedicated single place where something (potentially, a complicated graph of dependencies) is assembled as a whole, and as such, it isn't really meant to be configurable at runtime by client code (so, it's not like a DI container, although it may use one; it basically produces an assembled thing based on a spec and/or a convention). Any interface you can think of to provide this kind of flexibility to clients is going to be either less powerful or more complicated then just letting the client itself assemble the dependencies. So if a library (or a framework) has a Composition Root and just returns the end result (the composite), most (or all) of that decoupling and modularity is lost from the perspective of the client. Again, this is an impression I get from the way he writes about it, but maybe I'm wrong.
Regardless, the bottom line is, it's OK to provide reasonable defaults for your library, but it's a good practice to do it in a way that lets clients inject dependencies of their choice (their own "C") if they wish to do so. This makes both B and C more reusable (and likely more useful to other people, as those libraries will more easily support scenarios that you haven't anticipated during development). Using an internal DI Container to provide those defaults is probably an overkill in many cases.
As for the other statement:
2) "A DI Container should only be referenced from the Composition Root. All other modules should have no reference to the container."
In his book, right before this line, Seemann talks about how we should be careful not to misuse the (single) DI Container as a Service Locator. I'm under the impression that that's the primary motivation behind this recommendation. A Service Locator is effectively a global object that classes can use internally to request their dependencies anywhere in the codebase (more or less), and this can turn out to be bad in various ways.
There are some other concerns related to maintainability of the code. If you open the article you referenced, and scroll a bit down, there's a comment where Seemann writes:
The problem with letting each module register their own types to any
sort of container is that it tightly couples the modules (and any
application in which you might want to use them) to a specific
container. Even worse, if you ever need to consume a service provided
by one module from another module, you'd have to couple these two to
each other. Pretty soon, you'll end up with a tightly coupled mess.
However, this comment is a bit handwavy, as there is a great deal here that depends on exactly how you do this. For example, the aforementioned Facade also couples a library to its dependencies, but the coupling is confined to the Facade; the core component of the library stays decoupled. These concerns are a bit more high level, and can become an issue in an evolving codebase, where you need to carefully control the dependencies and remodel things in order to support those changes and manage complexity, and where you need to effectively communicate the design/architecture to other developers working on the same system.
