In 2015 the Montreal team looked into this problem. As part of this effort I wrote 
https://docs.google.com/a/google.com/document/d/1XYIRJLLpgQm8AqKVGt27r_Vu0BhorOrJAKQmetRpI2s/edit?usp=sharing

Another note:
If
1) "Chrome for desktop" and "Chrome for Android" are synced
2) A bookmark is synced across "Chrome for Android" and "Chrome for Desktop"
3) "Chrome for desktop" and "Chrome for Android" use a different favicon of type FAVICON for the bookmark
e.g. Chrome for Android uses icon1.png 64x64px
     Chrome for Desktop uses icon2.png 16x16px

Chrome sync does not know whether the "Chrome for desktop" or the "Chrome for Android" version is correct. The "Chrome for Android" favicon might clobber the one on "Chrome for desktop" or vice versa.

Can you elaborate what the actual issue is? From the description above, it seems the only issue is that Chrome will download both icons, one being unnecessary/redundant.

Improving this would be nice (less data usage etc.) but of lower priority if Chrome can properly choose the most appropriate icon (in a nutshell, largest).

There are two different problems with multiple icon URLs
1) Chrome sync does not work well when different clients (e.g. Chrome for desktop and Chrome for mobile) use different icon URLs

Example:
1) Ensure you have an Android device and a desktop browser which are both signed into the same sync account
2) Make sure that reddit.com is not bookmarked on either client
3) Clear history from the beginning of time on both clients
4) Navigate to reddit.com on the desktop browser (Windows or Linux, not Mac or CrOS). Bookmark the site. Notice that the bookmark uses the alien head favicon (www.redditstatic.com/favicon.ico)
5) Wait for the bookmark to sync to Android
6) Clear history on Android (Alternatively you can continue to step #7 in a week. The repro steps still work even if you visit reddit.com multiple times during the week that you are waiting)
7) Navigate to reddit.com on Android. Ensure that you "Request the desktop site" (this causes Android to navigate to https://www.reddit.com/ instead of https://m.reddit.com/).
8) Notice that the desktop reddit.com is now replaced with the full body alien (http://www.redditstatic.com/icon.png)

If you don't request the desktop site for reddit.com in step #7, your desktop bookmark icon will be replaced a read alien head (https://www.redditstatic.com/mweb2x/favicon/64x64.png)

Encouraging developers to list multiple-non-touch-icon favicon URLs on their page will increase the number of sites for which the desktop bookmarks will be clobbered by scaled down versions of the mobile bookmarks. reddit.com is the only site that I know of which uses multiple-non-touch-icon favicon URLs

2) - When a page has a single favicon URL we use the favicon cached in the history database and don't download any favicons
   - When a page has multiple favicon URLs we don't use the favicon cached in the history database and download all of the favicons (We will likely hit the HTTP cache in this case).

From a historical perspective solving the multiple-icon-URL bug was never prioritized. However, it is frustrating to enourage developers to change their pages in a way which will increase how often the mobile favicon clobbers the desktop bookmark favicon.

Thanks for the detailed explanation! I believe youtube.com and other popular pages also provide multiple-non-touch-icon favicon URLs.

Wrt to problem 1:
Is this related to providing multiple icons? Wouldn't reddit reproduce the issue you describe, even if it only provided one per platform, as long as they are different?

Taking a look at components/sync/protocol/favicon_image_specifics.proto, the different resolutions are split for sync purposes. Should we introduce dedicated fields in FaviconImageSpecifics such that mobile+tablet is separated from desktop?

Also, in reality, most users have a single device, so the priority of this bug might be lower than anything that causes a drop in mobile large-icon impressions.

1) Yes, we would have a similar issue if reddit dynamically generated its <link rel="shortcut" href="" /> based on the user's platform.

Thankfully, reddit.com has a different URL for mobile. (Though that does not help us much because reddit.com issues a redirect to m.reddit.com when a user navigates to the reddit.com on mobile and we propagate favicons accross redirects)

The bookmark favicons are sent to sync via https://cs.chromium.org/chromium/src/components/sync/protocol/bookmark_specifics.proto?q=bookmark_specifics&sq=package:chromium&dr

Peter, thanks for the detailed example!

I would like to understand the case of "multiple favicon URLs on a page".
 - Is any of the downloaded icons stored to the cache (for later use such as for icons on new tab page)?
 - If so, how is it selected?
 - If not, can it happen in the future that an  icon fetched from the google favicon server and stored to the cache as expired will outlive a later visit to such a page and stay in the cache?

Answers to comment #8:

In the case of "multiple favicon URLs on a page"
1) Are any of the downloaded icons stored to the cache (for later use such as for icons on new tab page)?
Yes, the icon for the best icon URL is stored to the cache
2) If so, how is it selected?
The logic for selecting the "best icon URL" is complicated and is different on mobile and non mobile. On desktop the "best icon URL" is determined by the icon for which CreateFaviconImageSkia() returns the highest score. Multi resolution favicons (.ico files) are preferred. On mobile, the "best icon URL" is the "icon URL" with the largest bitmap
3) If not, can it happen in the future that an  icon fetched from the google favicon server and stored to the cache as expired will outlive a later visit to such a page and stay in the cache?
The favicon fetched from the google server and stored to the cache as expired will outlive a later visit to such a page only if the user is browsing in incognito mode

Completely unrelated note. Improving support for multiple favicons in the Chrome database is perhaps not the most important favicon-related bug to work on.  crbug.com/471743  might be more important.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e9abde5a831c773c8e0ab85605254a591246925f

commit e9abde5a831c773c8e0ab85605254a591246925f
Author: Mikel Astiz <mastiz@chromium.org>
Date: Mon Nov 26 10:14:50 2018

Avoid unnecessary favicon downloads on desktop

Prior to this patch, desktop favicon downloading would only stop when
a truly ideal icon is found, which means a favicon with perfect bitmaps
sizes for all supported screen densities (often a .ico file with a
16x16 AND a 32x32 bitmap). This often leaded to all icons being
downloaded, even for cases where it's obviously unnecessary.

The patch adopts the logic we currently use on mobile within
FaviconHandler::UpdateFaviconCandidate() in order to stop processing
favicon candidates if there is little hope that the next ones will be
any better.

This requires some smartness for favicon candidates without an explicit
'sizes' attribute, which would score very low prior to this patch and
hence would rarely be processed (if other candidates exist). Hence,
we special-case them for desktop and score them highest during initial
sorting, which mimics the behavior prior to this patch and guarantees
they will be processed unless an ideal favicon is found before.

It's rather trivial to rule out regressions for the following common
scenarios:
A. Mobile platforms: no behavioral changes as score stays zero for
   candidates without explicit 'sizes' attribute.
B. A single favicon is listed by the page.
C. Multiple favicons are listed and none have a 'sizes' attribute
   (sorting does nothing and all are processed unless an ideal one is
   found).
D. Multiple favicons are listed and they all have an accurate 'sizes'
   attribute (scenario improved in this patch).

The more complex scenario is when a web page lists multiple favicons
and only some have a 'sizes' attribute. In this case, there is some
minor risk for regressions given that the patch scores highest the
favicons without a 'sizes' attribute, so they will be downloaded and
processed earlier.

Bug:  895175 , 705900 , 672076 
Change-Id: I8216652ede25f55332cacc54d3e0a806fd8b7bc3
Reviewed-on: https://chromium-review.googlesource.com/c/1323551
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Reviewed-by: Peter Kotwicz <pkotwicz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610800}
[modify] https://crrev.com/e9abde5a831c773c8e0ab85605254a591246925f/components/favicon/core/favicon_handler.cc
[modify] https://crrev.com/e9abde5a831c773c8e0ab85605254a591246925f/components/favicon/core/favicon_handler.h
[modify] https://crrev.com/e9abde5a831c773c8e0ab85605254a591246925f/components/favicon/core/favicon_handler_unittest.cc

One remaining low-hanging fruit here would be to in-memory cache icon sizes for all processed candidates (independently of the chosen one, which ends up persisted in HistoryService).

With the recent improvement above, and the discussion during code review concluding that it's not worth introducing such cache, I'm marking this bug as fixed.

There's room for improvement (for the desktop case for pages with multiple favicons without sizes attribute), but overall it seems like we do a decent job already (and sites can mitigate limitations by providing sizes information).