Since connman does not track AP mac address, there is no way it can tell the difference. What would happen first is that it would try to autoconnect, get/send an invalid-key error, and then go though this new code.
Can't act on different MAC addresses because that would stop handover/reconnecting on corporate networks which have several AP's assigned same SSID/password.

If they didn't change the password, it would still have the invalid-key failure in it's properties/settings (like it would regardless in that scenario), but at least now, it would try to autoconnect (not get stuck requiring a manual connection) sending the input request to agent/user.

I just tested this scenario (same SSID, different pass/encryption type), it does popup more than once, but only after some amount of time (2 minutes?). Problem is, any property we set for the fake known AP will effect the real known AP.

It's better than getting stuck without an auto-connection when the real known AP comes within range again. To the user, it appears the auto connectable service just does not work, requiring them to forget/remove the service to be able to connect again.