1. There's currently no such feature, but there's an RFC for one: #5099
It's only scheduled for PoL v5 however, and even then maybe not on first release.
An alternative for now to manually updating each virtual drive could be something like
sed -i.bak -e 's/^VERSION=1\.7\.47$/VERSION=1.7.48/' ~/.PlayOnLinux/wineprefix/*/playonlinux.cfg
replacing the Wine versions for your transition. Be careful with that though ;)
2. PoL is not involved in this "migration" procedure, and I could reproduce the problem you describe easily, so I think it's a Wine bug also.
If you look at how it's implemented, Wine normally creates those user directories in virtual drives as symlinks to what it considers counterpart directories in the hosting system (probably using $HOME if it can't find the directories it expects, hence the mess). Disabling this integration in the interface replaces those symlinks with empty directories.
So two workarounds for you:
- instead of disabling the integration, make them point to another "sandbox" directory you created; This won't be overridden by Wine version changes. This is what I use, using the "CentralizedUserDirs" pseudo component, and why I didn't notice this bug before;
- putting anything in those empty directories prevent them from being replaced by symlinks during Wine version changes. I don't know if it's a feature, or just makes rmdir() fail, but it works. I just modified "PrivateUserDirs" pseudo component to use this trick.
Notice you can customize newly created virtual drives using the undocumented post_prefixcreate hook script.
Both "PrivateUserDirs" and "CentralizedUserDirs" modify all directories integration, including Desktop, so they may not be exactly what you want. Their implementation is quite straightforward, so you could use a modified implementation directly into a post_prefixcreate script.
When is desktop directory integration useful though?
Edited by petch