Has anyone seen intermittent cases of a message saying incorrect password on an iOS 13 device? The password is definitely correct on the device. The user was moving between the WPA2 SSID and an open SSID.
This is an end-result that could have quite a few root-causes, frustratingly enough. This is where the ability, and capabilities, related to "Information Gathering" determines just how long your RCA (Root Cause Analysis) efforts will last. In other words, the more information you're able to gather at the exact time of the issue's occurrence the sooner you will be able to identify the potential Root Causes (that need to be addressed), where the value of any/all information gathered "after the last occurrence" decreases as the "time since the last occurrence" increases.
One example that provides multiple (potential) root-causes (i.e. Misconfigured AP and/or Rogue SSID/HotSpot):
If there is an SSID being broadcast with the same name ("Press"), but has otherwise been configured differently than your "Press" SSID (i.e. Same name but different method of authentication(s), which could include a different PSK) and the iOS device sees/hears that version of the SSID at a higher RSSI (i.e. sees it at a stronger signal, subsequently satisfying the requirements of the device's algorithm that pertains to "Wireless Signal Selection") then that iOS device will attempt to connect to that SSID and yield an "Incorrect Password" error if that SSID (with the same name) has been configured to use a different PSK than yours.
Information Gathering for the above scenario would entail (at the least) obtaining information related to every signal that can be heard by the iOS device at the time it connects to the SSID/Network named "Press" and subsequently yields the "Incorrect Password" error. This would then allow us to identify all BSSIDs (MAC addresses of the Wireless Access Point(s) Radios) broadcasting any/all SSIDs/Wireless-Networks in range of that [iOS] device, ultimately allowing us to identify whether those BSSIDs heard actually belong to the BSSIDs we expect to be heard at that location. (This could be accomplished with something like Xirrus' WiFi Inspector, inSSIDer, etc... in combination with various tools inherently available to our Xirrus APs.)
So coming back to your question/comment, I would say that these issues are best attacked in a completely unbiased manner each and every time they occur, as in this day and age they will inevitably occur.
As opposed to immediately assuming a particular Version/Release/Update of a Network and/or User Device is the potential culprit.
(i.e. Threats from all angles will likely strike on the heels of common Release/Update schedules so as to mask the source/vector of attack.)
And if/when a particular Version/Release/Update of a Network and/or User Device happens to actually be the culprit, then Information Gathered in that unbiased manner will absolutely identify that as the culprit while also serving a dual purpose in Gathering the Information Developers/Engineers need to [properly] implement the code/changes necessary to address the issue.
If this issue is occurring on a Network sporting Xirrus APs, please feel free to open a Support Case and mention my name (Kyle Meyer) and I will be more than happy to dive into whatever is necessary to idenitfy the culprit here. (I will of course follow up on this post with our findings, should you take the aforementioned route.) Otherwise, I will be happy to address any and all of your comments, questions, and/or rebuttals to this response.
Staff Engineer, Xirrus Products