I finally isolated the bug in builtin GLOB. Consider the following example:

# Jamroot file at C:\Jam.
# A dummy text file at C:\AaA\BbB\File.txt

using msvc ;
import path ;

path-constant TOP : . ;
ECHO [ GLOB $(TOP)/../AaA/BbB : * ] ;

We execute:

C:\Jam>  bjam

The output should be:

C:\Jam\..\AaA\BbB\File.txt

but in fact is:

C:\Jam\..\aaa\bbb\File.txt

I think there might be a bug either in:

a) canonicWindowsPath() (pathnt.c). It takes as input a normalized string like c:\\jam\\..\\aaa\\bbb\\file.txt. Notice that folder separator are normalized windows-style (\\), and all characters are lower-case. At some point, it uses FindFirstFileA() and replaces the first part of the path, until "..", with the correct one as read from the filesystem, leaving the rest unchanged: "c:\\Jam\\..\\aaa\\bbb\\File.txt. Funny: the file name is ok, it just leaves the normalization in the subdirs between the ".." and the file name.

b) path_key() (pathnt.c). It normalizes the input string. Surely because that's a pre-requisite for canonicWindowsPath(). The point is: why does canonicWindowsPath() have such a pre-requisite?

I guess any solution will need to fix canonicWindowsPath() anyway, which states itself as "FIXME: work-in-progress". I tried to replace most of its code with a call to Win32 API GetFullPathName() but it didn't work. May someone more experienced have a look?

Regards.