Is this problem still happening?  If so, did you try using
unmsys--file-name to solve it?

The problem is of course happening. I've also discovered why it does not happen in `trunk'. The reason is that due to "FORCE" phony, this target is simply never run in the `trunk'. Furthermore, since "macuvs.h" already exists and is under source control, as a temporary fix, I simply decided to disable this target similarly to `trunk', until the appropriate fix is found.

Sorry, but I haven't tried `unmsys--file-name' yet.

To be honest, from my point of view, workarounds like `unmsys--file-name' all over the place are not a good idea. Look at the path passed:

/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/IVD_Sequences.txt

I get it that on Windows, Emacs currently gets confused and as a last resort tries to prepend "c:", hence:

Opening input file: no such file or directory, c:/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/IVD_Sequences.txt

I believe it's better to teach it to treat "/C" as "C:" by default, i.e. to accept both variants because there is no ambiguity here and, as a result, it will support both Windows and MSYS(2)/Cygwin paths out of the box.