I agree with @imetallica that a private module shouldn’t be accessible at all (or maybe inside of its own file), otherwise it would be strange. Maybe a different name like protected or internal would make more sense.
But speaking about the functionality, I like the option C with some considerations. I believe that is too early to add visible_to, it adds some complexity and issues described before, and for the problem described I believe that having something like require MyApp.Private, as: Private, allow_private: true combined with defmodulep would be enough. Internally, the team should know where to use it, and, externally, you can still get a error that can be bypassed if you know what you’re doing. In this case, private maybe still makes sense, since you’re bypassing it.
