Yeah, unfortunately the Mac firmware isn't cognizant of degraded RAID sets. If the system boots from a degraded RAID set where the "kicked" disk is still readable, there is a chance that the firmware will load the bootloader and kernelcache from the "kicked" disk. Once the kernel is running, the OS correctly handles the RAID set and uses only the "live" disk(s). Should an OS update be installed while the RAID set is degraded, the kernelcache on the "kicked" disk will not be updated, leading to the scenario you encountered: The running kernel (loaded from the "kicked" disk) is pre-update, while the rest of the installed OS is updated.
Fusion doesn't handle that situation well at all, with the inconsistency promptly triggering a host kernel panic. We do have an open feature request to make Fusion detect this and ensure we don't trigger a panic. I can't say for sure when that will make its way into a public release of Fusion, but I'm hoping it's not too far away. 
Now that we've figured out the cause of your system's panic, are you aware of any other issues with Fusion brought about by the 10.8.4 update itself which might warrant a Fusion update? I haven't heard of any, but if you have, please be sure to let us know!
Thanks,
--
Darius