>
> 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.