We wanted visibility rules to be simple and consistent.
So “private” means that member will be accessible on the same level as declaration and all nested declarations. Top-level private function is accessible at the same package and all sub-packages. Class private function is accessible in the same class and all nested classes. It is more natural than Java approach, because packages have logical semantics of nesting into each other, and their visibility scopes are nested in Kotlin, too. We also have “internal” visibility, which is assigned by default, if you omit visibility keyword: it means that member is accessible from the same module, but not from other modules and library users.
Use case for private visibility of package members is the following: you may have some utilities for implementing interface, which are not interesting to interface users. You make it private.
I think that the most clean way for implementing your functionality in Kotlin is the following:
parser
±- public ConfigParser
±- public ConfigEntry
±- (some public facade for creating parser)
±- impl
(private classes and functions which are common for implementations)
±-xml
±- internal XmlParserImpl
±- private DomReader
±- json
±- internal JSONParserImpl
±- private LineBeautifyingSplitter