There's no reason you couldn't have the user pick a new password before you send them the token. Just don't activate it. Leaking the reset token in this way looks unlikely, but there could be other vectors... like an attacker poisoning the sites DNS cache to intercept reset emails, or a state or database disclosure bug in your code.

It's fairly common to see reset tokens going in to the database verbatim, instead of treating them as passwords and stashing away a hash (single SHA is fine if your tokens are long and random).

There is a reason not to do this: at the point where you cache the new password, you have no idea who's making the request. An attacker banks a trivial password into the password reset, triggers the email reset token, and waits for the unsuspecting user to click the link in the email. So you have the user enter the password again after clicking through the token. But now you have a condition where accounts are only as safe as it is difficult to get users to type an attacker-chosen string into a web form.

Hmm, can you explain how this opens up new phishing vectors?. Sure, you could dress the reset page up like a promotion with an iframe and try and get the mark to enter a 'coupon code' or something, but that isn't going to work without the reset token. Password resets by email are already vulnerable to carefully timed phishing.