what are guidelines for when to split a module into a package?

[Timothee Cour]

from my perspective it makes sense to split a module M into submodules
A, B when:
* M is large
* there's little interaction between A and B (eg only few symbols from
A are needed in B and vice versa)
* A and B are logically grouped (that is domain specific)
* it doesn't turn into an extreme (1 function per module)

Advantages of splitting:
* easier to review
* easier to edit (no need to scroll much to see entirety of module
we're editing)
* less pollution from top-level imports as they only affect submodule
(likewise with top-level attributes etc)
* more modular
* doesn't affect existing code since `import M` will continue to work
after M is split into a package
* less memory when using separate compilation
* allows fine-grained compiler options (eg we can compile B with `-O` if needed)
* allows to run unittests just for A instead of M
* allows selective import in client to avoid pulling in too many
dependencies (see arguments that were made for std.range.primitives)

Disadvantages of splitting:
* more files; but not sure why that's a problem so long we don't go
into extremes (eg 1 function per module or other things of bad taste)

---
while working on https://github.com/dlang/phobos/pull/6178 I had
initially split M:std.array into submodules:
A:std.array.util (the old std.array) and B:std.array.static_array
(everything added in the PR)
IMO this made sense according to my above criteria (in this case there
was 0 interaction between A and B), but the reviewers disagreed with
the split.

So, what are the guidelines?