I was helping 3 weeks in Support and have seen this problem there a couple of time only in these three weeks.
And also In know it from development and training, that this is very often a problem.

The problem:
When a module is already installed and registered in config:modules, but the modules wants to re-install. That happens when either:

• the module registry breaks, was moved or anything alike
• the version property was deleted
  Then the module tries to re-install and is denied, because it can't bootstrap the bootstrap files (UUID conflict).

Also in development/training:
I've seen it many times, people break the config:modules/modueRegistry and restart.
Module can't be re-installed.
Or even more often: they want to explicit re-install the module to test something, remove it from config:modules and restart, but forgot some node with a uuid also in bootstrap files (but in a different place).

Effect:
One can just not startup Magnolia anymore!

• In support I had to create to the customers a patched jar, removed all the bootstrap files.
  Just that they can startup again and fix the config:modules problem.
• In development one needs to remove the deps from the webapp's pom and hope no other module has a deps to it. And start up.

Both are situations, where all what is needed is that the system starts up again.
Often just to see what happened and fox it, or even more likely get unsaved work out of the repo for a complete proper re-deployment.

Solution:
The solution would be easy, I see two possibilities:

• a magnolia.properies value that can be switched, that will just not bootstrap anything form any module. Very handy for development (and auto install option combination).
• when not using the auto install option: On the installation screen, where it states that the module can not be installed a button with "Ignore and proceed". Advantage, it would ignore it just for the one module needed.

I thin both are achievable with not much effort.

Cheers
Christan