thanks for the report @hamby please test

The logic is if the account's password changes, the need to reset the password goes away.

As is, this PR will break the functionality because that line is the only spot in the CMS that sets the flag back to false. So you're going to need some extra logic somewhere to make this work with the condition you've described.

Ah got it. So we need to check if the user is currently in the PW reset step or not. In the first case we need to reset the flag and in the latter case we need to keep it. Correct?

Why should it matter how the password reset was accomplished? As far as JUser is concerned, the user's password was reset therefore the requirement to change it is invalidated. Yes, this means a second save is required if you want to set the user password from the admin and still require that the user change their password, but without overcomplicating the code or making a potentially B/C breaking change and requiring any downstream implementor to change the flag if a password is reset (think extensions which add custom user management options that extend JUser and the core users table), I'm not sure what other options exist right now.

JUser should not have request based logic within it, so it should not be responsible for figuring out if the user profile is being updated.

Closing based on the discussion above as expected behavior.