Thank you for forwarding this bug report! The fix has been applied to libtool's development branch with a new test file. :)

https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=b165ea8e0a165be58da1af7c6a0ac5e9de1f8eff

Autoconf bug #108503 reports a conflict between the advice given by libtoolize and the advice given by autoscan:

> Let's say that, in an empty directory, I have a configure.ac file
> that looks like this:
>
>   AC_INIT([testcase])
>   LT_INIT
>   AC_OUTPUT
>
>
> Then I autoreconf, which puts ltmain.sh into the current
> directory. Now when I run autoscan, it produces the following
> warnings:
>
>
>   Local-Admins-MacBook-Pro:autoconf_bug_reports_dir localadmin$ autoscan
>   configure.ac: warning: missing AC_PROG_CXX wanted by: ltmain.sh:960
>   configure.ac: warning: missing AC_PROG_INSTALL wanted by: ltmain.sh:1028
>   configure.ac: warning: missing AC_PROG_MAKE_SET wanted by: ltmain.sh:2163
>   configure.ac: warning: missing AC_PROG_RANLIB wanted by: ltmain.sh:2455
>
>
> So I add these macros to my configure.ac, and now, when I autoreconf
> again, it includes this warning:
>
>
>   glibtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
>
>
> If I then go and remove AC_PROG_RANLIB, autoscan will then warn
> about it being missing again the next time I run it, leading to an
> endless cycle of conflicting warnings.

This is happening because _LT_CMD_OLD_ARCHIVE (invoked by LT_INIT) inlines the body of AC_PROG_RANLIB, so autoscan does not know that $RANLIB will be set.  If _LT_CMD_OLD_ARCHIVE were to AC_REQUIRE([AC_PROG_RANLIB]) instead of embedding AC_CHECK_TOOL([RANLIB], [ranlib], [:]), there would be no problem.

AC_PROG_RANLIB has used AC_CHECK_TOOL since the beginning of the VCS history for Autoconf (in 2001), so if this is a workaround for a very old autoconf that used AC_CHECK_PROG instead of AC_CHECK_TOOL, I don't think it's necessary any more