Fundamentally I guess we're trying to simultaneously satisfy the constraints of
(1) make NT symlinks, regardless of type, behave like Unix symlinks, to any host filesystem utilities
(2) make absolute symlinks still work when the prefix is moved, without any additional work
Which, barring some brilliant idea, I think just isn't possible, not without rewriting how said host utilities work, either by preloading our own bits of glibc, or maybe introducing some mount-point-like API to the kernel.
Personally, I think dropping constraint (2) is preferable to any hack involving preloading. Manually fixing up symlinks after a prefix move feels equivalent to manually prepending a wrapper before any filesystem operation, but it would have to be done far less often.
I also think it makes more sense to drop constraint (2) than constraint (1). I suspect moving a prefix is very rare in practice (though to be sure I have done it myself a couple times), whereas accessing the Win32 filesystem from outside is probably quite common. Additionally, it ends up being far less work to rely on host symlink resolution than to have to implement it ourselves.