This change sounds like a great idea. The visibility of this directory has been a point of friction for years: many users consider the visible files/directories in their home directory to be under their control, and run into problems when they move or delete files in this directory.
With that said, I do have a few concerns about this:
Apps expanding $SNAP_USER_COMMON/DATA in config files
I noticed the Chromium snap references the absolute path to its $SNAP_USER_COMMON in a number of its config/data files. Most seem to be log files, but the ~/snap/chromium/common/chromium/Local State file looks to be configuration and starts with:
{"autofill":{"states_data_dir":"/home/james/snap/chromium/common/chromium/AutofillStates/...
It doesn’t look like we did any special migration of this file when moving from a deb, so I suspect this will work. But it makes me wonder how many other snaps end up writing out absolute paths like this.
Migration performed outside of user context
This is basically the same issue as other home directory access performed on refresh: on some systems a user’s home directory will only be available while they are logged in. The main situations where this can occur are encrypted home directories and automounted NFS home directories.
These are both fairly niche use cases at the moment (e.g. I don’t think we prompt people to set up an ecryptfs home dir for a while), so it might be easier to say they are unsupported. But if systemd-homed takes off on some distro, that could change.
Has any thought been put into whether the migration could be completed at snap run time, if we find that it hasn’t happened for a particular user?
Bind mount shenanigans
I’m not sure how much of an issue this one is in practice for ~/snap, but there are a number of threads on this forum where we’ve suggested people create bind mounts when snaps are trying to place data on volumes that have run out of space (e.g. this one about LXD).
If ~/.snap is on a different file system to the files in ~/snap, then at best the migration is going to be quite slow as it copies things over, and at worst might fail after running out of space.
Again, it might be best to say these setups are unsupported. But it’d be nice if snapd doesn’t fall over if it encounters them.