ReactOS uses linker magic. My point is that there is no valid reason for the WINE code in kernel32 not to use RtlAllocateHeap since the WINE kernel32 code is only intended to run on ReactOS (where RtlAllocateHeap is available) and WINE (where RtlAllocateHeap is available). Therefore, re-writing wine kernel32 to call RtlAllocateHeap instead of HeapAlloc and perhaps changing WINE to do the linker forwarding foo (if such a thing is possible) is a good solution.
Other parts of the code in both ReactOS and WINE (dlls, tests or whatever else may be run on windows 9x) can just pull in kernel32.HeapAlloc like any other windows app would.
As for libwine_unicode, I havent looked but I suspect that on real windows, most of what libwine_unicode does is inside ntdll.dll somewhere. Therefore, lets put the libwine_unicode code into wine ntdll.dll, add the forwarding hooks needed from kernel32.dll that call ntdll.dll and then make WINE apps call kernel32.dll instead of libwine_unicode. Problem solved, plus its how MS does things AFAIK (which is always IMO the way that WINE and/or ReactOS should do things)