Can you talk about the implications?  Is this causing bad behavior?

It can cause subtle bugs in SecureChannel:

(0) Accounts A and B both are present on Android phone C.
(1) Log in as user A. User A's devices, including phone C, sync to CryptoHome.
(2) Log in as user B. User B's devices, including phone C, sync to CryptoHome. User B has logged in at a more recent time, so it has synced a more recent version of device C to CryptoHome.
(3) User B signs out.
(4) At the log-in screen, EasyUnlock tries to contact devices. First, user B's account tries to find a connection to phone C and fails.
(5) Now, user A's account tries to find a connectino to phone C. It provides the old/stale version of phone C to SecureChannel, and SecureChannel blindly overwrites the stale version in its RemoteDeviceCache.

Now, because the stale version has replaced the newer version, the device may fail to find the device (e.g., due to out-of-date BeaconSeeds).

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

commit 87cb87ca124b303f0ad60a304c1fdf6ba7b53ed6
Author: Kyle Qian <kyleqian@google.com>
Date: Thu Jun 28 00:56:37 2018

[CrOS Multidevice] Keep RemoteDeviceCache up-to-date.

Previously, RemoteDeviceCache would blindly overwrite any existing
device with a new one when SetRemoteDevices() was called. However, this
can cause subtle bugs in the case where SetRemoteDevices() is called
multiple times with devices possessing identical device IDs.
Specifically, if a device with stale information replaces a
more-recently-updated device, this can cause stale fields to replace
new ones.

This CL modifies RemoteDeviceCache by only updating the device residing
in the cache when the incoming device has a last update timestamp that
is more recent than the timestamp of the existing entry.

Bug: 856746, 824568,  752273 
Change-Id: I5a178ac8d360efef7ceb1c6dae7478484978515e
Reviewed-on: https://chromium-review.googlesource.com/1117305
Commit-Queue: Kyle Qian <kyleqian@google.com>
Reviewed-by: Kyle Horimoto <khorimoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570987}
[modify] https://crrev.com/87cb87ca124b303f0ad60a304c1fdf6ba7b53ed6/chromeos/services/device_sync/public/cpp/device_sync_client_impl_unittest.cc
[modify] https://crrev.com/87cb87ca124b303f0ad60a304c1fdf6ba7b53ed6/components/cryptauth/remote_device_cache.cc
[modify] https://crrev.com/87cb87ca124b303f0ad60a304c1fdf6ba7b53ed6/components/cryptauth/remote_device_cache_unittest.cc

Unfortunately, I needed to revert the changes in Kyle's CL (comment #4) due to a server-side bug erroneously does not update the "last update time" field when a field is change from "supported" to "enabled" or vice versa. My change to remove this logic is here: https://chromium-review.googlesource.com/c/chromium/src/+/1192417

Azeem is filing a server-side bug; once that issue is resolved, we can re-land the changes noted earlier.

Server bug: b/113299690