Do you have logs from the system?

What I suspect (not confirmed w/o logs) is that after this recent CL https://crrev.com/c/690581, if you  just do "crossystem clear_tpm_owner_request=1" and reboot, cryptohomed detects this situation and automatically re-owns the tpm after reboot (since it assumes it continues the interrupted initialization - it received a "can attempt ownership" signal but the tpm is not owned yet).

To make sure the tpm is not auto-re-owned either do powerwash or add "rm /home/.shadow/.can_attempt_tpm_ownership" to "crossystem clear_tpm_owner_request=1".

Though encrypted stateful (with home directories) should not have survived "crossystem clear_tpm_owner_request=1" in any case.
If you had some local files in one of the user dirs and can still log in and see those files after the steps described in this bug, that's a separate issue.

After adding rm -rf /home/.shadow/*/, it works. Thanks! 

But it seems that the file '.can_attempt_tpm_ownership' does not exist. 

For the issue from comment #3 one possible scenario is that reboot happened before the tpm ownership was actually established (and that can take up to a minute, and the user can login before the tpm is owned), in this case "crossystem clear_tpm_owner_request=1" effectively turns into a NOP and nothing changes upon reboot. Again, need logs to check if that's actually happened.

Re #4: Oops, my bad, it is actually "/home/.shadow/.can_attempt_ownership". Looks like a PSA is due anyways to prevent such surprises in the future - will send shortly.
For now closing this bug as WAI.

Thanks! Looking forward to the PSA.