How, why and when to use the ".Internal" modules pattern?
I've seen a couple of package on [hackage](http://hackage.haskell.org/packages/archive/pkg-list.html) which contain module names with `.Internal` as their last name component (e.g. `Data.ByteString.Internal`)

Those modules are usually not properly browsable (but they may show up nevertheless) in Haddock and should not be used by client code, but contain definitions which are either re-exported from exposed modules or just used internally.

Now my question(s) to this library organization pattern are:

 - What problem(s) do those `.Internal` modules solve?
 - Are there other preferable ways to workaround those problems?
 - Which definitions should be moved to those `.Internal` modules?
 - What's the current recommended practice with respect to organizing libraries with the help of such `.Internal` modules?
How, why and when to use the ".Internal" modules pattern?
===

I've seen a couple of package on [hackage](http://hackage.haskell.org/packages/archive/pkg-list.html) which contain module names with `.Internal` as their last name component (e.g. `Data.ByteString.Internal`)

Those modules are usually not properly browsable (but they may show up nevertheless) in Haddock and should not be used by client code, but contain definitions which are either re-exported from exposed modules or just used internally.

Now my question(s) to this library organization pattern are:

 - What problem(s) do those `.Internal` modules solve?
 - Are there other preferable ways to workaround those problems?
 - Which definitions should be moved to those `.Internal` modules?
 - What's the current recommended practice with respect to organizing libraries with the help of such `.Internal` modules?