Setting the virtual hardware may have changes on the code paths in the hypervisor. Just because there are not many differences in the VMX do not let that fool you into thinking there are no other consequences.
A guest OS and its version are supported by virtual hardware and firmware, the emulation inside the hypervisor for the virtual chassis (e.g. virtual SATA, SCSI...), plus the actual VMX code. For example using 10.6 on ESXi 5.5 invokes hidden CPUID masks for compatibility.
Note that I am not saying you need to change the level of hardware supported, just be aware that it may not be the most efficient way to run the guest.
Understood. I'm curious if you (or anyone else) is actually running ESX (or Workstation) on an actual Mac box? It would be interesting to know if you are required to choose HCV10 in order to choose 10.9 as the OS.
That is the way it seems to be in Workstation 10 when I use your unlocker - just wondering if that is the way it would be even with Mac hardware?
I would assume most people trying to use OSX as a production desktop will be running it on Workstation - so upgrading to HCV10 is not really an issue. For me, I like using the vSphere Client for ESX, so I don't want to move my HCV to 10. Being how 10.9 (and earlier) all seem to work fine for me - I'm ok. Of course, as I mentioned, I don't use OSX for a desktop - I use it for some software testing, and it seems to work well enough (I don't test things like usb, sound, ideal graphics, etc).
Slightly OT - but is it possible that your update to the unlocker script that compresses the image could possible have fixed issues with vSphere connected ESX boxes? Since I reinstalled with the compressed image, things *seem* more stable to me.