Connecting to an AP can be broken down into 3 steps: 
- authenticate (not the WPA auth, just registering your MAC addr with AP)
- associate
- configuration (getting an IP via DHCP)

Throughout this process, we obviously need the radio to stay on the same channel as the AP and not do anything else ideally. 

wpa-supplicant allows for radio 'atomicity' with the concept of radio-work. See: https://w1.fi/cgit/hostap/plain/wpa_supplicant/README
(section 'external requests for radio control'). 
Like entering and exiting a critical section, with starting and end a 'radio work' block, you are guaranteed that the radio won't be doing anything else. 

In the logs, I am finding that authentication and association are one single radio work block labelled 'sme-connect', but there is no such block protecting configuration i.e getting an IP.
In fact, getting an IP is done by shill which spawns off DHCP and _it seems that_ wpa-supplicant is oblivious of this. 

This is problematic because wpa-supplicant notices that sme-connect is done, and seems to be "dequeueing" previous task requests, like a previous background scan that would move the radio. 

This bug is an open-ended question. Possible answers could be: 
(a) add a 'radio work' block around configuration so wpa-supplicant waits to do other radio stuff. 
(b) consider intelligently aborting previous scans if we've just found an AP that we like and have already associated with.
Ofcourse, this cannot be a blanket abort - i.e. a user could very well click 'connect to GoogleGuest' in the UI and then change their mind and click 'connect to Google-A' before getting an IP, in which case it would be wrong to abort a pending scan on association.