The part your question already sensed, and it is the most interesting one: what happens to existing sessions.
The scenario that matters: somebody else has access to the account and is signed in. The owner resets the password. If existing sessions survive, the attacker is still logged in and the reset achieved nothing.
So on a successful password change:
Invalidate every other session for that account. With server-side sessions this is a delete. With stateless tokens it is harder - you need either short expiry plus a check against a value that changes on password change, or a revocation list. This is one of the clearest practical arguments for keeping server-side sessions in a small application.
Keep the current session signed in, or sign them in fresh. Signing the user out immediately after they set a new password is a common and irritating choice.
Email the account to say the password was changed, with a note about what to do if it was not them. This is the one control that catches an account takeover the owner would otherwise never notice.
Also worth doing: require the current password to change it while signed in, and re-authenticate before changing the email address - because an attacker who can change the email owns the reset flow entirely.