R devel - Feb 2023 - Regenerate m4/gettext.m4 with updated AM_GNU_GETTEXT?

Currently, m4/gettext.m4 contains an old version of Autoconf macro
AM_GNU_GETTEXT relying on internal symbols (e.g., _nl_expand_alias)
to detect broken implementations of GNU gettext.  System libraries
are searched for the internal symbols unconditionally, i.e., even
when linking against a static GNU libintl, resulting in the following
false positive in my config.log:


     configure:53900: checking for GNU gettext in libintl
     configure:53937: clang -o conftest  -g -O2 -Wall -pedantic 
-mmacosx-version-min=11.0 -arch arm64 -falign-functions=8 
-Wno-error=implicit-function-declaration -fPIC -DPCRE2_STATIC 
-I/usr/local/include -I/opt/R/arm64/include -I/usr/local/include 
-L/opt/R/arm64/lib -L/usr/local/lib conftest.c -L/usr/local/lib -lpcre2-8 -llzma
-lbz2 -lz -licucore -ldl -lm -liconv /usr/local/lib/libintl.a 
/usr/local/lib/libiconv.a >&5
     Undefined symbols for architecture arm64:
       "__nl_expand_alias", referenced from:
           _main in conftest-0e23fb.o
     ld: symbol(s) not found for architecture arm64


AM_GNU_GETTEXT was revised in the GNU gettext sources ~6 years ago
to address this:


     $ git log -1 b67399b
     commit b67399b40bc5bf3165b09e6a095ec941d4b30a97
     Author: Daiki Ueno <ueno at gnu.org>
     Date:   Thu May 26 13:38:57 2016 +0900

         m4: Rely less on internal symbols

         * gettext-runtime/m4/gettext.m4 (AM_GNU_GETTEXT): Skip checks for the
         internal symbols _nl_msg_cat_cntr, _nl_domain_bindings, and
         _nl_expand_alias, if __GNU_GETTEXT_SUPPORTED_REVISION is defined.
         Problem reported and fix suggested by Masanori Ogino in:
         https://lists.gnu.org/archive/html/bug-gettext/2016-04/msg00000.html
         The rationale behind this is: (1) those symbol checks are for detecting
         certain broken implementations, namely NetBSD and Solaris 7, and
         (2) __GNU_GETTEXT_SUPPORTED_REVISION is not defined in those
         implementations, while it is defined on compatible implementations,
such
         as musl-libc which doesn't have those internal symbols.


Can m4/gettext.m4 be regenerated from a sufficiently newer release
of GNU gettext, without major disruption?

Mikael