Ah the wonder works of Ken Kato. 
You may want to look at building the VMware Tools, particularly from the FreeBSD distribution-- given it's heritage ties to OpenStep/Darwin. I think you'll have much better luck than investigating undocumented APIs.
Someone posted some reverse-engineering of how this works,
Ah, very interesting link - thanks! Looks like heavy stuff, though, and not easy to port. I'll have a look, in any case.
What I find interesting is that from the description of the (reverse engineered) API, it's always the client side/the tools that initiate communication. Obviously, the optimal solution for my problem would be for the virtual machine[/i] to send information to the client side/the tools that the client just woke up from sleep/suspension and therefore needs time synchronisation, because otherwise you end up polling for the correct time in unnecessarily short intervals. Interestingly, this actually seems to be what the VMware tools do with respect to time synchronisation, as the VMware PDF you pointed me to says on page 14:
"The VMware Tools time synchronization daemon is quite simple and has a few limitations. The daemon checks the guest clock only once per minute[/b]." \[emphasis is mine]
The only contradicting information is that you said that "the VGA driver tells the guest when the window has been resized" which suggests that communication can be initiated by the host side, too.
I don't know if there's an official API.
Judging from my short googling, it seems there isn't. 
I find this hard to understand - wouldn't it be in VMware's best interest to encourage the creation of tools for as many OSes as possible?
You might try VMware's Community Source.
I'm afraid that being just an individual, they won't let me in ...
I now had a look, and unfortunately, all the relevant tools are binary only, no source.
The docs make clear, however, that this would do what I'd need:
"The VMware Tools Service performs various duties within the guest operating system, such as:
Passing messages from the host operating system or ESX Server to the guest operating system."
God only knows why VMware does not open the source for these tools. It would only help them sell more virtual machines. Oh well ...
I now had a look, and unfortunately, all the
relevant tools are binary only, no source.
There are some driver sources but I agree probably
not what you're looking folder
Yep, that's what I meant with "not relevant" ... 
FreeBSD:
Linux:
Ah, so there's a lot more Linux sources! I'll have another look, though I doubt it will be successful ...
OK, so if any, then the code in vmhgfs-only is the relevant one:
backdoor.c --
*
First layer of the internal communication channel between guest
applications and vmware
*
This is the backdoor. By using special ports of the virtual I/O space,
and the virtual CPU registers, a guest application can send a
synchroneous basic request to vmware, and vmware can reply to it.
*/[/code]
Unfortunately, the guest->host direction seems to be better documented and easier to realize than the host->guest direction I'd need.
And even if it were documented as well, these are only library modules in a larger context that isn't documented, and then there's Linux kernel code involved. So porting that kind of code, if possible at all with the information provided, would certainly not be a weekend project ...