After all, the guest cannot have any security from the host because processes on the host can potentially examine and modify arbitrary locations in the guest's memory directly.
Sure, that's a given. I don't think anyone is expecting any protection of the guest from the host OS. But I'm not worried about the host -- my host (be it Fusion on OS X or Workstation on Linux) is already trusted, that's why it's hosting the VMs in the first place.
What I'm extremely concerned about is VM escape of the guest -- it shouldn't be able to touch or influence anything in either the host or other guests.
Cross-platform file associations could be something as simple as a stub application on Mac OS that just shuffles the file into a temporary shared folder then sends a command to Windows to open the file. It could even stuff the file into Windows' own temp directories on the virtual drive. That doesn't require any communication functionality that does not already exist in Fusion.
The best way I can see it working would require dynamically setting up a shared folder with a hard-link to the file, giving the guest R/W access to said shared folder, mounting it in the guest, and opening the file. That way, changes are made on the actual file. Detecting when the file closed and tearing down the shared folder would be a little weird and would probably involve new functionality in Tools to monitor the number of open handles to the file in question. This would also make temp files weird. The way to get around that would be to just share the parent directory of the original file and work on it directly, but that would let the guest potentially see more files than it should.
Really, since this is a consumer product, cross-platform file associations should probably work by default or have a dialog the first time you start Fusion that says "Hey! We have a cool new feature that lets you open files on your Mac in programs in your VM!".
I don't really agree with that. The average consumer has already shown he doesn't understand the security implications of running an out-of-the-box Windows install with an internet connection. Providing any means of VM escape by default for that situation sounds like a recipe for disappointment/disaster to me.
Note the "or" in my statement. I personally don't like the idea of enabling it by default, which is why I suggested the dialog. Kind of like iTunes' MiniStore dialog the first time you ever launch it.
At any rate, the only real security risk would be to the VM, which already has no security other than what the host provides. As long as the VM can't request arbitrary files from the host (i.e., the files or shared folders are pushed), then malware in the VM could only affect things the host lets it affect. Similarly, malware on the host could already do whatever it wants to the guest, so that direction doesn't matter.
Personally, if Fusion were to add those sorts of features, I'd be most comfortable if VMWare offered two different builds (or at that point broke it into two different products), one with the actual code that provides those back-channel paths removed. Just disabling the features with config params or such is better than nothing, but I'd rather have no chance of some unrelated issue escalating into a VM escape via those codepaths...
They know that quite a lot of us want a version of Workstation, but that is probably a lower priority than Fusion, which is explicitly a consumer product. I wouldn't expect the code paths to be removed from Workstation Mac or whatever, if it is ever actually made. Rather, they would probably be implemented as things that you would either install or not install in Tools and enable or disable in the VMM.
As I mentioned above, there is at least one way to potentially implement this functionality that would not require any more "VM escape" potential than already exists via VMware Tools.