Issue solved!
Thanks to Bruno Haible in
https://lists.gnu.org/r/bug-gnulib/2019-08/msg00064.html
Quoting that message (and my reply):
---
On 2019-08-24 3:36 p.m., Bruno Haible wrote:
I think the problem is that 'bmake' does not consider the targets
'foo' and './foo' as being the same.
And indeed,
GNU hello and GNU datamash (which exhibit the problem)
have something like this in their Makefile.am:
hello_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
datamash_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
While sed and coreutils (which don't have the problem) have:
sed_sed_LDADD = sed/libver.a lib/libsed.a
LDADD = src/libver.a lib/libcoreutils.a
So because of the "$(top_builddir)" the targets gets a "./"
prefix, and combined with that recent automake change,
they ended up being considered separated targets by "bmake".
---
So the immediate fix/work-around is to remove any path from
the libraries listed in xxx_LDADD in the projects themselves.
However,
This change (regression?) seems to come from automake, perhaps
consider a bugfix for future versions.