The suggestion to handle modules and crates separately is a good idea. You might also be able to separate out visibility rules as well though I’m not sure. I’m not sure if having to point out the visibility changes every time you make a module change is a good thing. It kinda hides the rules in a wall of text.
It might also be better to start with modules and build up to crates (not sure how this suggestion would interact with the previous comment). Then, you can just say a crate is a special case of a module with these features:
As it is, you’re special casing a crate based on something the reader might not understand yet (modules yet to be discovered). That’s just asking the reader to backtrack to remember what the original definition of a crate is when it is mentioned again. Might be hard to remember.
Actually, as it is it isn’t very clear on the distinction between modules, crates, and packages from the description. A crate is a special case of a module that only occurs at the top level. A package is then at the top level where it encloses multiple crates. These concepts seem similar and the distinction between them might not be clear.
Also, if you ignored modules from external files for the time being and then covered visibility and private/public separately, you could probably rely on the previously defined explanations when pointing out briefly how modules can be externalized almost as a shorthand.
(I hope that made sense…)