Defining private modules and functions is like defining blacklists. The other approach would be to define whitelists. So instead of defining private modules / functions. Only those which are whitelisted (public) would be exposed to outer world.
I think this would be the way to go. Maybe its something for elixir 2.0, but I think it would make the language more stronger for the future.
just my 2c on this topic in general
We can’t have compilation errors with A because it is best-effort. It would be jarring to have compilation fail only from to time or in a later optional pass. If you want errors, then you need the require mechanism and a separate namespace.
That’s a good point and we can discuss other names. However, that would be too specific for now. 
So instead of worrying about the names themselves (such as scope/defmodulep), can you please share your thoughts on the proposal in considering the merits of the mechanisms instead, regardless of names? Thanks!
My preference would be A, D, C, then B. B is out because of the reasons already stated.
I’m concerned about this being an error, because it’s effectively a backwards incompatible change. This changes the meaning of private from, it’s not documented to I’ve explicitly marked it as private. Which means that everything that was considered private before isn’t. I may have been calling something that was private before and now because B or C were chosen, my code fails to compile. This is quite similar to using a private API and Elixir changing it and my code breaking.
It wouldn’t be a backwards incompatible change as all existing forms and macros would remain the same. It would be a new macro with new functionality.
If someone changes defmodule MyApp.Foo to defmodulep MyApp.Foo, ..., that is backwards incompatible.
I do not think, that introducing defmodulep would invalidate the former meaning of @moduledoc false.
The latter is “You use this at your own risk” and will ever be, the former is “You are not allowed to do this, and I will try the best I can to not let you pass beyond this point”.
And if a @moduledoc false module becomes defmodulep, well, you have been warned before… There never was a promise or contract to not remove that module…
That would be a backwards incompatible change in the library in question, not in the language itself. It would be the same as the library author renaming a function, or removing a module.
If people start making their modules private, won’t it lead to the same problem this is trying to address?
I was assuming Elixir would start using private modules as well.
You can choose it happening one last time or it happening for the next 2 decades of the language.