This has been a known but minor issue for a little while. Up until now, in the development setups it all works smoothly, so I had not been able to isolate exactly what was going on.
However, just today, working with a user who is a premium support subscriber, I was able to pin it down – at least insofar as knowing “what” is happening – I still haven’t figured out the exact “why,” although I have a good idea what that is.
When the key is used to retrieve the user ID, it should be a unique value. Unfortunately (and leaving out some specifics here for sake of space), there are instances where that isn’t happening – there are multiple users with the same generated key. I’m fairly certain the cause is object caching.
So what happens is that the process queries only for the first result, assuming it’s unique that should return the correct user. But in these error situations, it’s returning a different user, who would of course have a different timestamp for the key, hence the expiration notice.
I had planned some changes to this process anyway, because I need to make some changes for tighter integration when other plugins are also used that rely on WP’s user processes. Since correcting this problem requires some digging into the process, it seems now would be the time to implement those changes.
For the time being, you can deactivate the setting for the feature and use the old password reset. The new process I should have complete and tested before the end of the week (hopefully in the next day or so) and will post it as an available patch file (the whole process is already contained in a single file, so patching it will be as simple as replacing that file). Then it will be incorporated into the next available update.
The patch will be announced on the premium support site’s blog feed (https://rocketgeek.com/blog/) which also displays in the sidebar of the plugin’s main options panel, so when it’s out, you will be notified that way.