Contrary to what is suggested here (and not just by cce but by several others in this thread) the OP is aware of this style of code organization, has examined it carefully, and has decided it is insufficient for his purposes. He explained this in his long post above:
OP has written something that I certainly wished for many times when learning Julia. He has also made a good argument that there’s a real use case for PatModules.jl: When you are developing a large package and you write functionality (like utils.jl) used in several places in your package, but for whatever reason, don’t want to split utils.jl into its own package, and yet you want to be clear where the functions in utils.jl come from so they don’t appear as random names all over your package.
Even if this is not a reasonable thing to want, the OP wanted it and went to the trouble to implement it himself before telling us about it, and is not forcing anyone to use it. Perhaps his initial tone was not optimal, but he has tried to clarify that he’s not trying to insult anyone. The great thing about open source software is that it allows people to write whatever they want, and the great thing about Julia is that it makes this sort of experimentation easier (can you imagine rewriting Python import logic in a package?).
@patrick-kidger I say well done, and time will tell if this package provides a sufficiently elegant solution to a sufficiently common problem that it gains more traction. I wouldn’t give too much weight to the initial reactions here; just keep making PatModules.jl awesome. If it’s awesome enough, people will use it.