Hi Cameron,
For the purposes of this explanation, power outage, reset, and crash are the same.
I'm not sure whether you have floating or persistent desktops, but that's important because it affects the way this all works. Floating desktops create interesting challenges in power outage scenarios with respect to data loss. On persistent desktops the local profile is on the desktop and if the machine crashes the data can be recovered on the next logon (assuming the data was successfully written to disk before the power went out). This is not the case with floating desktops unless the user is lucky enough to get reassigned to the same desktop on the next logon, which is not likely.
That said, here's some details of how the replication engine works. Every ten minutes (default) or whatever you have configured, the changes made during that interval are uploaded to a hidden temporary directory in the root of the roaming profile. This folder name is a guid that starts with {d2...}. Once that step is complete, the data is merged into the roaming profile itself. If something like a crash or a reset happens before or during the upload to the temp directory, the upload is considered invalid and thrown out. Anything else would result in a corrupt profile (i.e. a partial upload would result in a profile that is not in a crash-consistent state). So, if a user changes a file and the machine goes down before all of the data from the delta is uploaded, the changes would be lost on a floating desktop scenario. The replication engine is designed to ensure a crash-consistent state in the roaming profile in all cases where it's possible for us to ensure that.
So, if the VM of a logged on user gets reset or crashes, it's very likely the user can lose data for the reasons I explained above.
If the host goes down, I think this is a similar scenario as the VM crashing. If the datastore hosting the desktop goes down, I think this is again a crash scenario. If the connection to the central profile store is lost during the user's session, Persona will cache the changes locally and replicate them once the connection is restored. Again, things get complicated if the user logs off while the CPS is disconnected on a floating desktop or if refresh on logoff is enabled.
You are correct, "{08C31585-259A-4341-9982-78E42EAF6106}\computername.0.lck" is created by Persona and it is how we ensure only a single session is replicating to the roaming profile. I'm sorry the support person told you this is not created by Persona. They were definitely wrong. Unfortunately, if the desktop loses power while Persona is holding this lock, sometimes the file server will not receive the signal to release the lock. This not really a Persona bug as much as it is a catch-22 within the file system. Imagine you and I were on the phone and I pulled the plug on my end, but you kept hearing my voice. You wouldn't know to hang up because I kept talking and didn't say goodbye. Basically, the file server isn't hearing "goodbye" and doesn't release the lock. The file server should release the lock when the Persona service process stops (even if Persona didn't close it explicitly), but that doesn't happen cleanly in a this kind of situation, so it doesn't get the "goodbye" message. I am not sure if this a persistent bug in Windows, NTFS, etc of it's a design issue that Microsoft cannot work-around.
The profile will not work correctly again until the lock is cleaned up. At this time, the only way I currently know to clean up the orphaned file locks is to reboot the file server.
So, yes, we can expect data loss to happen if the desktop is reset unexpectedly and the data hasn't been replicated yet in some cases. Sounds like this may be what you are experiencing. Profile corruption is a term often misused. In your case, I think you are seeing data loss due to the outages, not profile corruption. I would expect your roaming profile to be in a crash consistent state, but missing the last set of changes the user made. Is that what you are seeing?
I hope this helps to answer your questions. If not, please feel free to ask more.
Thanks,
Erik