gcc one-tree build with newlib on MSYS2 broken due to top-level include?

Hello Newlib!

In RTEMS we build a one-tree gcc cross using newlib. We have
historically just symlinked the newlib directory into gcc, e.g.,
something like...
 $ git clone sourceware.org:/git/newlib-cygwin.git
 $ cd gcc-13.3
 $ ln -s ../newlib-cygwin/newlib .
 $ configure ... --with-newlib ...
etc. This has worked pretty well for a long time, however we've seen a
breakage on MSYS2 builds for the arm target:
../../../gcc-13.3.0/newlib/libc/machine/arm/setjmp.S:5:10: fatal
error: arm-acle-compat.h: No such file or directory
    5 | #include "arm-acle-compat.h"

We tracked down this file is missing due to
https://sourceware.org/pipermail/newlib/2023/020082.html

We tracked the issue to this snippet:
-idirafter ../../../gcc-13.3.0/newlib/../include

Which is built in Makefile.am: 66
srcroot = $(top_srcdir)/..

Makefile.am: 73
AM_CPPFLAGS = $(NEWLIB_CFLAGS) $(TARGET_CFLAGS) $(AM_CPPFLAGS_$(subst
/,_,$(@D))) $(AM_CPPFLAGS_$(subst /,_,$(@D)_$(<F))) -idirafter
$(srcroot)/include

The problem seems to be only affecting Windows, due to the deep-clone
of newlib-cygwin/newlib as opposed to symlinking it. On OS's with
actual symlinks, the relative paths descending out of the symlink and
back into it are able to resolve the -idirafter path. On MSYS2 the
include path is not finding newlib-cygwin/include, it is finding
gcc-13.3.0/include.

Anyone have advice for how to build gcc with newlib in a one-tree
build on Windows (MSYS2)?

We have at least one person looking into this for cygwin and may
report back on it too.

Gedare