I like the idea, as I previously run into a few of those issues myself.
Back then, I proposed to mark a whole repository as .lowpriority (see internal ref.), so that (let's say) user modules will take precedence over (let's call them) system ones.

This could be solved by adjusting the order of the paths, where miniflask looks for modules: If one specifies user first, and system later, miniflask will find user modules first, and then the system ones. (Very much like the PATH environment variable in Linux)
Another option would be to assign every module a weight, and a heigher weight takes precedence.

What I don't like is the fact that the user has to know every other module in other repositories and take care of duplicates. What happens if the user uses his repository in another context? Will function calls like register_as fail?
This IMHO also contradicts the idea to loosely couple modules.

Thank you for your feedback.

I'll first summarize the feature proposals that we talked about in the last weeks and then comment on the pros and cons each.

Module-Name based replacement:
The idea is that module-directories are weighted by their definition order. When the user tries to load a module that exists in multiple repositories, the module with the highest weight gets loaded first.

Pros:

• the requirement for the user is to know the module name he/she wants to replace (besides the broad functionality)
• for module import chains a loads b loads c any subset of the modules a, b, c can be replaced by placing the corresponding module as well in the higher-weighted repository

Cons:

• the user can only define one module that replaces one specific other module, because the module name is the unique identifier that specifies what to load in that case.

Module-ID based replacement:
The user specifies in the module definition the module id of the module to be replaced.

Pros:

• the requirement for the user is to know the module id he/she wants to replace (besides the broad functionality)
• for module import chains a loads b loads c is also possible as mf.load behaves in a local-repository-first manner with this PR

Cons:

• using one single module as a replacement for multiple repositories (or as a standalone module in a third repository) is not directly possible. It would require the module to be replaced to have the same id in both repositories. It is, however easily usable as a standalone module.

Comment:
To allow a module to be replaced as a replacement for multiple repositories, we could add something like:

if mf.is_loaded("main.*"):
    mf.register_as('main.module.to.replace')
elif mf.is_loaded("othermain.*"):
    mf.register_as('othermain.module.to.replace.somewhere.else')

To be honest, I do not see how the first method gives a more loose coupling of modules and requires less knowledge of the repository to replace modules in. In both cases the user needs to know the module to be replaced in a broad manner (like the events it defines) anyway?

I think, both methods achieve more or less the same, however the second method allows multiple modules to serve as replacements for the very same module. Also, the method does not require the module to serve as a replacement to be placed in a separate repository.