Also love bazel (after using 2-3 years blaze), but for the use case above it would've been a real "killer" :)
In specific case of ninja build tool, it can be that they simply don't achieve the same speed on Linux and Windows, as JNRowe writes. It is known that NTFS and Windows are traditionally both visibly slower with many operations on many files, compared to Linux.
I always believed FindFirstFile actually does read the directory as a file once (or in some convenient chunks), keeps the handle to that and returns an element of that each time FindNextFile is called. Moreover, NTFS has some stat-like file information in the directory file, exactly to be able to return it this way. And as always, then the problem with having the cached information is, what if it is stale. But sometimes, for some purposes, it can be good enough.
Look at the WIN32-related ifdefs in https://github.com/ninja-build/ninja/blob/master/src/disk_in... (I would link to something specifically but it's not that long of a file.)
I would not expect problems, once there are no bugs in the code. As far as I understand, a build tool doesn't need file sizes, only the timestamps.
The code appears to do sensible things, e.g. it notes "FindExInfoBasic is 30% faster than FindExInfoStandard" and uses the former when possible.
Looking "from 20000 ft", the only to me unexpected thing I see is handling ".." there, somehow I expected that code which uses that wouldn't even need the timestamp of "..".
https://github.com/ninja-build/ninja/blob/master/src/disk_in...