When installing an add-on that has the same public route name as another add-on, the newly installed add-on takes over the public route and breaks the other add-on. For example, if you install an add-on that uses "resources" and you have the Resource Manager installed, resources will no longer be associated with the Resource Manager.
I'm sure this happens with admin routes too, but as most developers use a unique identifier with their routes on the admin side, it is not as apparent.
To get around this behavior I removed the public routes from an add-on I am currently working on, so they would not get exported and put them into the installer script to check if the routes were available or not. That almost worked, but when you install an add-on XF deletes all routes associated with that add-on (my install script installed them, then XF removed them) and then does the import from the XML file (if available).
The fix would be to either check for existing routes early in the installation process and warn admins that there is a conflict and ask to continue with the installation or not. Or, what I favor, is to not export any routes when exporting an add-on (and remove the XML importing of routes), and let the installation script handle it. If a developer creates an add-on that uses it's own route(s), then they most likely have an install script, and adding this check, then inserting their own routes if available, is fairly simple.
I'm sure this happens with admin routes too, but as most developers use a unique identifier with their routes on the admin side, it is not as apparent.
To get around this behavior I removed the public routes from an add-on I am currently working on, so they would not get exported and put them into the installer script to check if the routes were available or not. That almost worked, but when you install an add-on XF deletes all routes associated with that add-on (my install script installed them, then XF removed them) and then does the import from the XML file (if available).
The fix would be to either check for existing routes early in the installation process and warn admins that there is a conflict and ask to continue with the installation or not. Or, what I favor, is to not export any routes when exporting an add-on (and remove the XML importing of routes), and let the installation script handle it. If a developer creates an add-on that uses it's own route(s), then they most likely have an install script, and adding this check, then inserting their own routes if available, is fairly simple.