I agree with demerphq. Enforce restrictions through code, not organization. If Private::B should only be instantiated from the Public::A hierarchy, make that a requirement, document it, and enforce it in the constructor of Private::B. (With appropriate comments, of course!)

I can think of two very good reasons to do this:

1. Private::B might develop into a hierarchy of its own, either as the root parent or as some child of an abstract class you don't know you need right now.
2. There may be some Private::C that, while not sharing an abstract parent with Private::B, might make sense to have in some Private:: hierarchy. For example, you might want to restrict that all Parser::'s can only be instantiated by a Reader::. There might not be an abstract parent (though I would think there should), but there definitely should be a separate hierarchy ...

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.