Hi Mike,

The suggestion is good and the new version for 5.7 is under development currently so we appreciate all the feedback and feature requests from existing users. However, we generally try to avoid adding any features that do not add anything new or are not straightly related to the actual functionality of the add-on, i.e. pointing domains to correct pages. Also, as there are multiple versions of the favicons you need to include (different sizes for different versions of apple's devices, along with the others, plus we cannot see into the future which other versions are to come), I think it would just add unnecessary confusion to both, implementation and the UI.

Frankly I don't even think this feature belongs in the c5 UI either, we hardly ever use it ourselves. These tend not to change until a major brand renewal is done for the company and that usually happens only once in 5 or 10 years. Of course, there are different kinds of sites that need renewal every year, but even then it's once in a year task.

You are actually already able to do this in a couple of ways.

The first one would be to hard code these into the theme and checking there which favicon to show for which domain. Our docs guide you further in how to check that, e.g. the section for domain specific global areas or tracking codes, depending on whether you want to check against the ID or the domain.

The second one would be to use page attributes to define the icons and then use each of the home pages of the domains to define them, as we suggest for the domain specific titles in our documentation:
http://www.concrete5.org/marketplace/addons/multiple-domains/docume...

Using the same method, you are be able to define the site specific favicons and also define as many icons as necessary. This method also adapts to any future needs as it does not bind the implementation to the icons known today. Once a new icon is needed, you are able to add it as an attribute, if you want to define this through the UI.

Building such feature into the package would probably require you adding additional line into the theme's header as well so frankly I don't see the benefit of implementing it. But it might be a good addition to the docs, we will be looking into at a later date.

Best,
Antti / Mainio