How out-of-sync are the disconnect reasons reported by shill v/s wpa-supplicant? 
Can you elaborate all the scenarios where they differ and if we understand why?

There are a number of scenarios that could lead to the disconnect reasons between shill and supplicant differing.

One is where WiFi::PendingTimeoutHandler is called, following an inability to connect after kPendingTimeoutSeconds. Shill will determine what failure reason to output (using the auth/assoc reason codes from supplicant or any other information). Supplicant, on the other hand, doesn't consider this a disconnect because a successful connection was never made, and so won't emit any disconnect code.

Even within WiFi::ServiceDisconnected though, shill does not necessarily only use the supplicant disconnect code in determining what failure reason to provide. WiFi::SuspectCredentials, for example, infers a connection failure during 802.1X 4-way handshake as an EAPAuthentication failure, regardless of what supplicant says.

Triage nag: This Chrome OS bug has an owner but no component. Please add a component so that this can be tracked by the relevant team.