Using a 14.2 based package, I ran into:
...
(gdb) core /home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m64/outputs/gdb.debuginfod/fetch_src_and_symbols/corefile^M
^M
This GDB supports auto-downloading debuginfo from the following URLs:^M
  <http://127.0.0.1:8002>^M
Enable debuginfod for this session? (y or [n]) y^M
Debuginfod has been enabled.^M
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.^M
Downloading executable for /home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m64/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols2...^M
warning: Can't open file /home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m64/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols2 during file-backed mapping note processing^M
[New LWP 11699]^M
Core was generated by `/home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.'.^M
Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M
#0  0x000055555555468d in ?? ()^M
(gdb) FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: file corefile
...

AFAICT, everything is going well until the "Downloading" executable message, issued by this debuginfod_exec_query in core_target::build_file_mappings:
...
            if (expanded_fname == nullptr && build_id != nullptr)
              debuginfod_exec_query (build_id->data, build_id->size,
                                     filename, &expanded_fname);

            if (expanded_fname == nullptr)
              {
                m_core_unavailable_mappings.emplace_back (start, end - start);
                unavailable_paths.insert (filename);
                warning (_("Can't open file %s during file-backed mapping "
                           "note processing"),
                         filename);
                return;
              }
...

But somehow it returns with expanded_fname nullptr, after which we see the warning.

The query returns a scoped fd, and if it's negative it represents an errno.

If the errno is not ENOENT, the query will have issued a message in print_outcome:
...
static void
print_outcome (int fd, const char *desc, const char *fname)
{
  if (fd < 0 && fd != -ENOENT)
    {
      ui_file *outstream = get_unbuffered (gdb_stdout);
      gdb_printf (outstream,
                  _("Download failed: %s.  Continuing without %s %ps.\n"),
                  safe_strerror (-fd),
                  desc,
                  styled_string (file_name_style.style (), fname));
    }
}
...

But otherwise, the download fails silently, and you have to read the source code to understand why.

This is a reasonable default for general usage.

But for test-cases it's useful to be more verbose, to get more info for rare and hard-to-reproduce fails.

I think this is a reasonable default for