Depends on the Windows version and the configuration of the server-side when we talk about non-local disks.
Since Windows Vista, Windows does have an idea of symbolic links, but the semantics differ. But the more important problem here should be the path names, which follow a different syntax. For starters: single-rooted directory tree on the unixoid side and several drive letters as roots on the Windows side.
On the unixoid side symlinks are merely text files with a special flag. On the Windows side the underlying mechanism is called a reparse point. This tells the object manager to to pass it to particular registered filters (the meta-date for this is stored in the reparse points). Windows 2000 already introduced one type of reparse points known as junction points (roughly, but not quite, directory symlinks). With Vista they introduced symlinks to both files and directories, also on remote drives. And symlinks on remote drives are also supported to some extent.
The main point is whether the file system driver - when run locally - would do any adjustments to the paths Windows gets to see. In such a case it would work for certain local/relative symlinks. For absolute paths as targets things will get difficult and impossible to deduce what's meant. Same for remote symlinks links (to "network shares").
As for the Mac side I have no idea and it might make sense as a separate question. But as long as the server side conveys the information that this is a symlink, I see no problems, since they both follow the SUS semantics (unlike Windows).
Consider the Linux side mount points:
And now consider a symlink
/home/paul/fstab pointing to
/etc/fstab. They are located on two different volumes which Windows - if able to see them through a file system driver (which does work!) - can't tell belong together the way
/etc/fstab describes it. So the link, which Windows would see under a folder
\paul\fstab, even if translated, would point to
\etc\fstab, which doesn't exist on
/dev/sda2. And if that symlink would point to the relative path
../../etc/fstab things wouldn't change at all.
The gist: So while this is conceivable that you can get this to work for some corner cases, the fact that semantics and syntax differ on both sides of the fence makes it unlikely that you will find a practical and generic method that works.