I am wondering if this issue is related to CL at [1], which has been identified as the culprit for two other cryptic issues, see [2] and [3] (and should be reverted soon).

[1] https://chromium.googlesource.com/chromium/src/+log/188c1056bbfb9c98eca691c12f5641d4204f6066..0f65d25a4097959d977dbb1077717323438240a6 
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=712094#c12
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=715059#c4

The root cause of this is here:

https://cs.chromium.org/chromium/src/third_party/polymer/v1_0/components-chromium/iron-list/iron-list-extracted.js?dr=CSs&q=iron-list&l=149

keyBindings in the iron-list appear to override any conversion of 'enter' to on-tap.

I suspect that the reason we do not encounter this elsewhere is:
a) Most buttons embedded in a list item do the same thing as clicking on (i.e. selecting) a list item. This button does not.
b) Other places where we have, e.g. a dropdown menu in an iron list item use paper-icon-button which have 'tap' listeners in IronButtonState.

Reposting here a comment from https://codereview.chromium.org/2841873004, to explain why I think this iron-list erroneously has different keyboard behavior than other lists on our page.

Compare for example the search engines iron-list (chrome://md-settings/searchEngines) with this one. Repro steps to showcase the difference

 1) Tab to the 1st item in the iron-list, see http://imgur.com/a/lnqHJ:
    Search engines: The 1st "dots" icon is focused.
    networks: The entire row is focused.
 2) Hit tab one more time, see http://imgur.com/a/Y8XzI:
    Search engines: The focus goes to the 1st item *after* the iron list.
    networks: The focus goes to the button within the row.

As discussed in https://codereview.chromium.org/2841873004, the behavior of the network list is somewhat unique:

* Tab focuses the list (which focuses the current [defaults to first] list item).
** Enter/tap performs the default action for the item (connect or view details if already connected).

* A second tab focuses the 'details' button.
** Enter / tap / space [because its a button] views details.

* A third tab focuses the next element (i.e. not the list).

This is consistent with most of our iron-list implementations, with the exception that this list has both actionable items and an actionable button. Other lists have one or the other.

The root cause of the bug is described in comment #2. I don't think it is actually related to  issue 715889 , removing this from blocking that.

Since we agreed to special-case address this in the CL, marking this as WontFix.