I see little value in locking people out of being able to access “private” modules.
If I have to do something hacky that is my decision. I do not want to be unable to do what I need to do because a developer decided that THIS module should be private.
You could probably create a macro that flips things around depending on the Elixir version but it wouldn’t be supported by Elixir per se.
If you do not want a developer to decide what you need to do with the code written by said developer, maybe you shouldn’t be using their code? 
Would a combination of B & C be an option? I like the idea of being sure that I can mark a module as completely private. This is from the perspective however of working in a large codebase wanting to enforce the designed boundaries to other teams and less so about packages. Or would this make the heuristics of private modules more complicated to use?
You got it right: having both would complicate the heuristic. However, note the reason we decided to not go with B is not because of enforcing the boundaries to other developers, but because sometimes you may want to debug that code yourself, and making it fully private would not allow that.
Well, if defmodulep isn’t smooth to use with code that needs to support older versions of Elixir, I think I favor option A, which would allow simply updating private modules with that attribute, which (I believe) would then work if the version of Elixir was high enough and be ignored otherwise, which is a much smoother path to start using.
In terms of options C vs D, I think that if you want something to be possible (in this case, being able to ignore boundaries), it’d be better to just support it gracefully rather than make people jump through hoops to use it, adding cognitive overhead in the process (if it’s called as :“Elixirp.Foo.Bar”, it means x, if it’s called as Foo.Bar it means y).
I know that warnings are easy to ignore, but option C seems like a pretty hacky solution to imprisoning your cake but eating it too.
So my preference is, A, then D, then C in a far third.
While I believe being able to use it sooner is nice, it should play a very small factor. Do you want to choose something that is less optimal forever just to get a 1-2 years head start?
EDIT: to be clear. I am not saying you considered it as a big factor, just providing a counter argument.
Agreed, something being easier to use sooner shouldn’t be a driving motivation, though I do think it’s worth thinking that adding syntax which is not backwards compatible with previous versions of the language is a negative trade-off, particularly when it’s syntax for something as central as defining modules.
Potential reasons why it’s a negative trade-off include that it requires overhead to remember when you can use syntax in relation to supporting previous versions, and people wondering why sample code they copied off the internet is erroring because defmodulep is unknown.
That doesn’t mean it’s not a worthwhile trade-off: I don’t think I could live without with.
However, since I alternately favor option D- which requires much more invasive changes to achieve warnings similar to what A achieves- it’s a larger factor in my consideration.
To expand a little on why I favor D over C, I agree with @brightball when he says:
In my experience, private methods and modules cause more problems than they solve. They increase logic duplication, complicate debugging and if developers are trying to access them…the developers usually have a good reason for doing so.
Warnings won’t prevent code from breaking if a developer chooses to access private functionality, but I don’t know that the benefits prevent access to private functionality outweigh the benefits of allowing access, especially when the benefits to allowing access are such that we’re already adding loopholes to work around the restrictions.
It is not a new syntax. It is just a new macro/function. For example, if we add a new function to Enum, you can’t invoke it on earlier Elixir versions either. Should we stop adding functions to Enum and other Elixir modules?
There is even a proof of concept of the functionality working today.
Those are not the same warnings since we can guarantee those warnings with B, C, D, but not with A.
We are not allowing access because of external users, but for the authors of the private module themselves. It is a small distinction but it is an important one. Leaving the key under the carpet does not give permission for anyone else to get that key and enter your house - although you know it is a possibility when you do.
A minor thing, but naming is hard. You would not say “define module private”, more likely you would say “define private module” and when you talk about these modules you would not say “modules private” but “private modules”, we also have “defp” already in place, so how about:
defpmodule
?