"Current state" is changed right after taking snapshot

Description

"Current state" is changed right after taking snapshot

Scenario to reproduce the problem:
1) Power on a virtual machine and boot an OS in it.
2) Shutdown the machine cleanly.
3) Take snapshot of "Current State" and name it, for example as "Snapshot 1".
Problem: you will get the result as follows:
Snapshot 1 (1 second ago)

Current State (changed)

It incorrect that "Current state" is changed right after the snapshot is taken when the machine is turned off.
I use VirtualBox 3.1.2, host OS is Linux Ubuntu 9.04, Guest OS is Windows XP SP3. Virtual disk image file format is VDI.
I also could reproduce the problem on another 2 PCs with host OSs Windows Vista SP2 and Linux Mandriva 2010 and different guest OSs. So it seems it does not matter which host and guest OSs are.
The problem did not exist on VirtualBox 3.0.12. In that version "Current state" remains identical to the state saved in snapshot until the machine is powered on again.
I am not sure but probably this is the reason of virtual disk corruption described in #6023 (with more steps like taking another snapshot and removing a previous one). I could also reproduce the problem from #6023 on my systems.

Confirmed for VirtualBox 3.1.8 on Ubuntu 10.04. I suspect it does not matter whether the client system was shut down inside or just its state saved. Here's another way to consistently reproduce this: "Power off the machine" with "Restore current snapshot 'NameOfSnapshot'", "Snapshots" shows "Current State", select it and "Take Snapshot of Virtual Machine", "Snapshots" now shows "Current State (changed)". At first sight the logs are only about the sessions and don't include information about taking a snapshot at such time.

After some research, my assumption is an incorrect use of "SaveS_ResetCurStateModified" from inside Vbox/Main/SnapshotImpl.cpp, but this seems to have been corrected in revision/changeset 27644, on "2010-03-23 17:07:49 (2 months ago)", which may be after 3.1.8, without updating this bug report? I propose that somebody with 2 test machines tests 3.1.8 and 3.2.0 next to each other to verify, and then marks this as fixed.