I feel like I'm putting myself into the frying pan here, but I'll try to answer just a few of these... (Lots of the points you raise, such as anything DirectX or Unity, is waaaaay outside of my own sphere, although I try to help out with them where I can. I do know that Linux Unity support was a sink of far too much engineering and QA time than was justified by the feature's resulting quality and usage.)
Decide that it is a good idea to have a split disk have slices that can grow beyond 2GB in fact they decide to go past the 4GB limit when the VM disk is over 128GB and thus FAT32 is no longer a disk format that can be used to move your VMs to just about any OS.
There is an extremely good reason for this. Most host OSes have limits on the number of files that can be opened at once – per-process limits, system-wide limits, or both. If you create a 2 TB disk in 2 GB slices, that requires about 1000 file handles per snapshot in the chain, so even one disk with four snapshots puts you right up against the per-process handle limits of many OSes. With three such VMs running at once, you will exceed many OSes' system-wide handle limit. We are actually seeing folks hit those limits. (And even if you are not hitting the handle limits, there is a cost in terms of CPU, memory and I/O for each file opened... For thousands of files, it quickly adds up.)
We figured that using >2 GB slices when needed (and not gratuitously) was a reasonable compromise. If you have a moderately-sized disk, you keep the portability of the 2 GB slices. If you create a huge disk that will run the risk of hitting the handle limit, you lose the portability.
Disk repair on vmdk's that has been broken for several versions. In fact running vmware-vdiskmanager will always show an error even if you pass it correct parameters, since many versions.
Ulli pointed me to another thread about this earlier, which I've yet to investigate fully (been perilously busy on other things here), but please know that we have put a lot of effort into improving disk repair in WS 12 and Fusion 8. It's certainly still not perfect (and does not have artificial intelligence to deal with really complex corruption), but when we have concrete information on how we can improve the disk repair facility we've been making those improvements. Obtaining concrete and actionable information on this has sometimes been challenging.
The bogus error message with vmware-vdiskmanager and correct arguments should be gone in WS 12 and Fusion 8. Please let me know if you are still seeing it.
Reinstall VMware Tools to fix a VMware Tools issue is unreliable, also for many versions.
We've been begging for years for Microsoft to please kindly refrain from reverting our registry values and/or revoking our own permissions to our registry entries. To date, Microsoft has not seen the underlying issues as having high enough priority for them to address it, so Windows upgrades or service packs or patches intermittently continue to kill various features – most often, it's shared folders (HGFS) that's the unfortunate victim. Sometimes it's host services, too. As far as I'm aware, the nature of the problem means that until Microsoft stops hosing our registry entries, we are pretty much stuck with having customers uninstall/reinstall Tools or WS (or doing spot fixes) when things break.
Cheers,
--
Darius