>> Can you report the bug to VMWare?
Neither I nor @ColoradoMarmot work for VMware. If you want this reported as a bug so VMware can fix it, you can either see if some kind soul from VMware notices this on their own time (VMware doesn't actively monitor these user-to-user forums), or you can open a service request.
>> I'm worried that if I use the workaround and VMWare doesn't fix Fusion 13, my customers using Fusion/WinXP might run into the same problem every time they install a minor update in Fusion 13 if that update tries to reinstall Tools. Then I'd need to reapply the workaround, but my clients would be dead in the water until they can schedule me.
Once the workaround to install the correct version of Tools is done, you shouldn't have to worry about it again. First, any tools update offered by any future Fusion release that has this bug wouldn't install on XP - the installer wouldn't even start. Second, the 10.0.12 version of VMware Tools for XP VMs is the end of the line - so you should expect no need to update those tools.
You can prevent the XP VMs from attempting to automatically upgrade Tools by editing the .vmx file (with both the XP VM and Fusion shut down) and changing the line
tools.upgrade.policy = "upgradeAtPowerCycle"
to
tools.upgrade.policy = "manual"
The only time the workaround would have to be re-applied is if they manually uninstalled the Tools from within the VM.
>> In the mean time, my Fusion/WinXP customers will stick with Fusion 12 and macOS Monterey, though I want to move them to Ventura.
That's fine as long as you want them to stay on Monterey. Moving to Ventura will require Fusion 13. If your customers already have the correct VMware Tools installed in an existing XP VM from Fusion 12, you should have no issues moving them to Fusion 13. It's only if you're creating a new XP VM that you need to use the ISO file workaround.
- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
