Personally I feel like a lint like this, since it is about style more than anything else, definitely belongs in clippy, not rustc.
It was already discussed that this should be a lint in rustc itself during the stabilization of the module style change: https://github.com/rust-lang/rust/issues/53125#issuecomment-411174227
The intention is to primarily point people to
foo.rs. We want to keepfoo/mod.rsfor compatibility, so this change doesn't break existing projects. And we can provide appropriate lints (for people who want to write idiomatic Rust 2018 code) that encourage renaming the files accordingly, to help migrate the ecosystem.
(Emphasis mine; I'm interpreting this "we" to mean "the lang team of rustc"; Clippy is not mentioned anywhere in this discussion.)
I also feel that tying the lint names to the editions doesn’t make much sense
The other changes from RFC 2126, namely the absolute/relative path changes and making extern crate optional, are already part of the rust_2018_compatibility and rust_2018_idioms lint groups, respectively. I would bundle this under the latter. Also see the above quote; associating the new module style with the 2018 edition was intended from the start.
But I should probably mention I don’t experience this as a problem, since module introductions aren’t all that common.
To be fair, that's not really a good counterargument to introducing a new lint. Certainly a lot of lints rustc and/or Clippy have don't trigger for experienced users; you just don't write code that trigger them because you know better.
In my experience this issue happens when you have developers switching back and forth between various projects that use both styles and lose track of which one a project is using. Ideally you'd just pick one and stick with it but again, enforcing things procedurally is hard to keep consistent, not everyone has time to do sweeping style refactors of a dozen different projects (especially with no decent way to automate it), and if Rust is about one thing it's about building things most systems projects try to handle procedurally into the compiler itself.