No - the system first sends the secure random token, then instead of asking them for a new password then, it instead auto-generates a random password and emails it to them.
Then the system FORCES them to change the password when they login with the new password.
Oh - and the tempoary password only valid for 24 hours.
So you get the best of both worlds - without anyone being able to 'guess' anything able to do anything...
The system forces them to change the password if they actually log in. If they don't, the password just sits there. And some users will just cut/paste it.
I'm sure there's a million fiddly things you can do to address the weaknesses of temporary password issuance, but you'd be better off sending a semantically meaningless random token. All the countermeasures you're thinking of here apply identically to the token.
I am advocating for the reset scheme that is the hardest to mess up. Yours is not the hardest to mess up. I'm not trying to get you to change yours.
Then the system FORCES them to change the password when they login with the new password.
Oh - and the tempoary password only valid for 24 hours.
So you get the best of both worlds - without anyone being able to 'guess' anything able to do anything...