require + alias can be done in a single require call. The difference in usage between require and requirep is literally just the extra p.
When you alias, you can alias only to a single entity, like as: Bar, never Foo.Bar. Which is why we don’t implicit alias and you need to give it the :as bit.
You can’t because of the above. Aliases need to be explicitly given because you can only alias the “last bit”, and doing for everything automatically would generate clashes.
I know it’s the same call, I was just trying to say that I like the extra p.
Ok, but that’s how the normal alias works… We can define a new alias-like thing that works as I’m saying, can’t we?
I personally can’t see how such feature would work. Aliases perform expansion based on the first element and if we start to perform it based on subsets then it adds complexity both in the implementation and in understanding of the code, as Foo.Bar can now be Bar.Baz and Foo.Baz can be something else completely such as Enumerable.
You are right and I’m stupid for not seeing the obvious problem. It seems like name mangling is a hard problem to crack… 
Would this be valid?
defmodulep MyApp.Private, visible_to: [MyApp.*] do
end
I could see it becoming a tangled mess if we have to update visible_to every time we want to reference this module from another one of our private implementation modules.
Here’s a contrived example:
defmodulep MyApp.EmailWorker, visible_to: [MyApp] do
alias MyApp.Repo
alias MyApp.EmailService
def run(user_id) do
user = Repo.get(MyApp.User, user_id)
EmailService.send_welcome(user)
end
end
defmodulep MyApp.Repo, visible_to: [MyApp, MyApp.EmailWorker, MyApp.KafkaJob] do
end
defmodulep MyApp.EmailService, visible_to: [MyApp.EmailWorker] do
end
Then if I wanted to rename MyApp.EmailWorker to MyApp.WelcomeWorker, in addition to updating the places where EmailWorker.run/1 is called, I’ll have to go update MyApp.Repo and MyApp.EmailService as well. If this MyApp.EmailWorker interacted with even private modules this could be a much bigger task.
It seems like without visible_to: having a wildcard option, this will create tons of difficult to manage circular dependencies, that would serve as a huge deterrent to refactoring how private modules are laid out.
Personally, @moduledoc false and treating submodules as private implementation details of the parent modules seems like enough to me, but I get the pain people have caused by no respecting these conventions.
That’s how it works! 
visible_to is always by namespace for the reasons you mentioned. I don’t want to refactor code in MyApp to an internal module and then have to update the visible_to list.
Out of those, I’d strongly favor A or D.
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.
While taking the approach of exposing APIs as the top level is great, when a developer is working deep with a particular module there are often needs to dive into the weeds beyond the original developer’s intent to achieve your goals. If an overzealous use of private methods is in place, you end up in situations where you’re left to fork the module the code base just so that you can access / modify the method that you need.
While the intent behind private methods is good, in practice they are heavily overused and create a lot of problems for a developer. If I’m running code locally that applies to my application…I don’t want anything off limits, regardless of the original developer’s intent because I’m the one who will be maintaining and responsible for the application that’s using the module.
If I’m calling code on somebody else’s server, I’m 100% fine with the barrier. If I’m calling code on my own, the barrier just means that now I’m going to have to devote additional time and effort to get around it…and I’m still going to get around it one way or another.
What would it look like to start using defmodulep in libraries that need to support older version of Elixir than whatever version it is released in?
Is there some way to conditionally use it or defmodule based on the version of Elixir? Would it just not be available until the minimum supported version hits the version it was released in?