Assuming the user has a multifactor device and forgets their password, how should that affect the "forgot password" workflow?
If the user is initiating password reset from an unrecognized device/browser then a second factor of authentication should be required to perform a password reset. Best practice is to require the second factor consistently across all scenarios: Normal authentication (after verifying password) or Password reset (after verifying access to email link).
If the device/browser requesting the password reset is recognized, then two-factor authentication could be skipped after clicking an email password reset link.
What if the user loses the multi-factor device, or the soft token is corrupted, how should that be re-provisioned?
If the device/browser is recognized or if the user already has an authenticated session on the device then the user should be able to de-provision the lost second-factor device and provision a replacement second factor device.
If the device/browser is not recognized and/or the user does not have an authenticated session on that device then a backup two-factor authentication method must be validated before re-provisioning the second factor device.
What if the user forgets the password, and loses the token... what should the re-provisioning workflow look like then?
Emailing a reset link is sufficient to recover the password from a device/browser that is recognized as trusted*. After the user resets the password the user can go through the re-provisioning of second factor as described above.
If the user's device/browser is not trusted then the user must verify a backup method if the second-factor device is no longer available. This could be a SMS sent to a backup phone number, or a backup string that was provided when the two-factor authentication device was enrolled. Omitting this verification of a backup code negates that two-factor authentication was ever enabled. It must be performed.
See Google's help docs on 2-step verification for more information about how Google handles these scenarios. They've definitely thought this through and have a lot of good information available online.
* Where 'trusted' means that the user previously authenticated using two-factor authentication and indicated that the device/browser should be trusted for subsequent authentications (and to not require two-factor authentication again from this device).