I think that the reason for the existence of the separated add-ons repository for, for example, GNU IceCat is exactly because of the issues caused by the suggestions made by Mozilla's add-ons repository
As a somewhat unrelated issue, although still discussing the issues about dependencies, recommendations and suggestions: As recall watching a speech, whose video was shared here, in which they were discussing whether packages which were removed from repositories due to not being free software should also be removed from other packages' meta-data/controls. The reasoning for the removal from meta-data/control seems to be that the absence of such package and the presence of it in other packages' meta-data/controls makes these packages "cite" the formers, and so contribute indirectly to non-free software dependency, recommendation or suggestion. So, for example, let's say that I'm a very novice free software student, and I have problems with my GPU, and I know how to use Aptitude, and I have heard from a "free software supporter", that's a "friend of mine" that "Linux" can load "modules", and that these can include GPU drivers. So in Aptitude I would find, FOR EXAMPLE: linux-image Suggests: - linux-modules-nonfree (NOT AVAILABLE) So now "I" have a "hint" as to what I should look for. A non-free software. But in the other side, the reasoning for NOT removing the associated meta-data/control from other packages SEEMS TO BE that could create quite complex situations where, although the package is know to work with the "newly acquired non-free software", it doesn't change the fact that the main package will still not use the "acquired non-free software". Furthermore, if the user decides to uninstall the free dependency/recommendation/suggestion in order to use the "acquired non-free software" as a replacement, the main package's meta-data/controls will be read by the system's package manager and the system will complain that the main package must be uninstalled. Personally speaking, I'm in favor of the removal of all references to non-free software in repositories and packages' meta-data/controls. Besides, to me, the complex situation used to describe the opposite argument's viewpoint could be easily solved by telling the package manager to hold the main package. Furthermore, to my understanding, the user who chooses to install the non-free package will still need to configure the main package to use the "acquired non-free package", and to me that would be something interesting to watch.
