@Torust, yes, the packages build, however, getting from building to working and stable is another journey :).
The file system representation in swift-package-manager is designed around the Unix semantics and those do not carry over very well for Windows. You can have NT paths, device specific paths, UNC paths, drive relative paths, non-canonical path separators in paths, DOS 8.3 style paths, extended paths, etc all pointing to the same file but are treated entirely different. As an example:
\??\S:\BinaryCache\Release\Windows-x86_64\swift-package-manager\bin\swift-build.exe\\UNC\S:\BinaryCache\Release\Windows-x86_64\swift-package-manager\bin\swift-build.exe\BinaryCache\Release\Windows-x86_64\swift-package-manager\bin\swift-build.exeS:/BinaryCache/Release\Windows-x86_64\swift-package-manager/bin/swift-build.exe\\?\S:\BinaryCache\Release\Windows-x86_64\swift-package-manager\bin\swift-build.exe\\.\Devices\HardDisk1\BinaryCache\Release\Windows-x86_64\swift-package-manager\bin\swift-build.exe\\UNC\localhost\S:\BinaryCache\Release\Windows-x86_64\swift-package-manager\bin\swift-build.exeS:\Binary~1\Release\Window~1\swift-~1\bin\swift-~1.exeS:\Binary~1\Release\Window~1\swift-~4\bin\swift-~2.exe
are probably all the same file path. However, the way that they are handled in tools-support-core does not account for that.
There are other file system issues like realpath, dirname, basename, etc do not currently function (e.g. while path.isRoot { path = path.parentDirectory } currently infinitely loops!)
There are other assumptions in swift-package-manager, such as the ability to use which (there is no which, where is similar, but a builtin shell function, which means you cannot exec it, you can do a cmd /c "where ..." but, that has its own set of problems - e.g. command line limits, environments, permissions, etc).
There are hardcoded tools in swift-package-manager (e.g. swift and clang) which cannot be used, as the .exe suffix is important, especially when there is an ambiguity due to directory and executable being named the same modulo the suffix. Furthermore, clang on Windows is a rather scary idea, and should instead be using clang-cl to ensure that INCLUDE and LIB are honoured correctly and that the ABI is conformed to properly.
Static linking is prevalent in swift-package-manager, but is not currently supported on Windows.
Although this something you can work around, llbuild assumes that the archiver is named ar rather than lib, or preferably llvm-ar. Fortunately, modern Unix has eschewed the librarian in favour of the archiver, so ranlib is not needed (and similar on windows, lib handles both tasks).
I doubt that there is anything insurmountable, but they add up very quickly.
CC: @Aciid