bootstrap & build-aux/funclib.sh are not maintained in libtool.  you'll want to send those fixes upstream.
https://github.com/gnulib-modules/bootstrap

It appears that the shell assignment expectation may be erroneous,
in that ": ${RM="rm -f"}" will only replace RM if RM is not defined.

perhaps what is intended is more along the lines of:
RM="${RM:=rm} -f"

(NB it would probably be easier to contend with separating
pure RM from, for example, RM_F (or RM_FORCE) for "rm -f").

This problematic construct seems to be found in at least the following files: bootstrap, libtool.in, libtool.m4 and funclib.sh

noticed on pkgsrc libtool 2.4.2 (patched)
as well as on master

libtool uses a construct in numerous places '${RM}r' where
if defined simply to the full path breaks miserably.

Here is a simple example (code source unimportant):

what works (this is after a --mode=compile stage):

richard@omnis:/home/richard/src/tlibtool$ ../libtool/libtool -v --tag=CXX --mode=link g++ -shared -o libfoo.la -Wl,-h libfoo.so foo.lo
libtool: link: rm -fr  .libs/libfoo.a .libs/libfoo.la
libtool: link: ar cr .libs/libfoo.a .libs/foo.o
libtool: link: ranlib .libs/libfoo.a
libtool: link: creating libfoo.la
libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la" "libfoo.la" )

what doesn't:
richard@omnis:/home/richard/src/tlibtool$ RM=/usr/bin/rm ../libtool/libtool -v --tag=CXX --mode=link g++ -shared -o libfoo.la -Wl,-h libfoo.so foo.lo
libtool: link: /usr/bin/rmr  .libs/libfoo.a .libs/libfoo.la
../libtool/libtool[1851]: eval[1]: /usr/bin/rmr: not found [No such file or directory]
libtool: link: ar cr .libs/libfoo.a .libs/foo.o
libtool: link: ranlib .libs/libfoo.a
libtool: link: creating libfoo.la
libtool: link: ( cd ".libs" && /usr/bin/rm "libfoo.la" && ln -s "../libfoo.la" "libfoo.la" )


libtool should naturally test RM prior to using as thus.