You probably already noticed it, but I only notice just now that the TESTFN
option also has been removed from the calling convention with
`(advertised-calling-convention (map key &optional default) "27.1")`. (Just
to add to my previous answer)

On Fri, 26 Mar 2021 at 04:59, Michael Heerdegen <michael_heerdegen@web.de>
wrote:

> Hi Stefan,
>
> we are discussing here the limitation for `map-elt' calls with alists
> caused by deprecating the TESTFN argument (done by you a while ago).
>
> What's a good way to solve this?  Obviously the map abstraction doesn't
> fit so super well for alists because unlike the other map type alists
> don't know "their" test function.  But disallowing alists that don't
> test with `eq' seems an unnecessary restriction.  Can we say that the
> argument is allowed only for alists?
>
> Regards,
>
> Michael.
>
>
> I <michael_heerdegen@web.de> wrote:
>
> > > > The docstring of the map-elt function from the map.el package
> (version
> > > > 3.0) mentions that TESTFN is deprecated because "its default depends
> on
> > > > the MAP argument". However when I try e.g.
> > > >
> > > > (map-elt '(("A1" . 3)) "A1")
> > > >
> > > > it returns nil.
> > >
> > > This is expected, as alist keys are tested with eq by default.
> > >
> > > That's what the docstring is trying to warn about: alists default to
> > > testing with eq, but can also use eql, equal, or anything else.
> >
> > Is it that obvious?  We have `assoc' and `assq' built-in - to me it's
> > not obvious that "alist keys are tested with eq by default".  It's the
> > default for `alist-get', ok, which is used by the implementation, but
> > not everybody will know that.  I would add a sentence about that.
>
>