I don't understand the desire to exclude files using mod. If you are including code from that file via use, then your build will still be broken. And if you're not, then the files would be excluded from the build anyway.
That messy state may include a new, partially-implemented module file. By default `git stash` will leave it alone, because it's untracked. But `git stash` will also remove its corresponding `mod` declaration, and any uses of it, all at once.
Now say you want to build and run. If that WIP module file gets picked up automatically, it will probably break the build! It may simply be incomplete, or it may depend on some of those stashed changes, or whatever else. Even if it happens to typecheck, now you're assuming that it's all dead code- but it may have some public API (including trait impls!), and still be included in the build!
In fact, we already have a taste of this kind of problem, ever since Cargo started running build.rs scripts automatically, even without a `package.build` key in `Cargo.toml`. If you add a build script with some build-dependencies, run `git stash`, and then build, the build script will fail to compile!
Perhaps you could argue that this is a deficiency in `git stash` that Rust shouldn't have to be concerned with. But if `git stash` removed untracked files as well, that would simply break other use cases instead! For example, I often have a few extra files laying around, which I don't ever intend to commit or .gitignore- sample inputs or outputs, short-term todo lists, or other scratch-pad-like data. Ideally `git stash` would leave those alone- but it's hard for git to tell those apart from the problematic cases above.
That is, my own personal workflow poses essentially zero risk of deleting or committing those files, so "quit using the file system the way I've always used it" is no less of a stumbling block for me than "maintain `mod` declarations" is for you.
We simply haven't found an approach that doesn't step on someone's toes, so the one that Rust was already using from the 2015 edition stuck.
They aren't though. Even if the module isn't `use`d, it's still compiled.
(And it has to be. If nothing else, there could be a trait impl buried in the module, which gets shared without `use`.)
Why would this be the case? Under this model, are we not allowed to have public symbols anywhere in a library but at the root? In other words, why should I have to "use" something from a module from elsewhere in this crate to get it to build?
I'm already hopelessly confused by your system. The current model is simple, correct, and efficient. No wonder people hate it so much - it's human nature to hate the unfamiliar!