In Unix, directory symlinks interact weirdly with `..`. If `a/b` is a symlink to `x/y`, then `a/b/..` actually points to `x`: `b` and `..` do not cancel each other.
I think you're misunderstanding what this is solving, or how it's solving it, which is my fault for not providing an explanation. Previously, when resolving a relative symlink, we do segment-by-segment resolution, as usual. Suppose we are opening a path like \??\C:\one\two\three\four where 'three' symlinks to '..\targetdir'. At the point we encounter the symlink, our half-constructed Unix path is '$WINEPREFIX/drive_c/one/two'. (We don't add 'three' because it's a reparse point.) We rewrite the NT path to \??\C:\one\targetdir\four. However, we (a) don't update the 'nt_pos' variable which points towards which segment in the NT path we're processing, and (b) don't get rid of the path segments we stripped from the Unix path. The end result is that we look for the file 'etdir' in the Unix directory '$WINEPREFIX/drive_c/one/two'. This commit fixes that by rewinding the lengths; it does not append '..' to the Unix path. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10678#note_136554