So there's the problem of repetition.  In info_line_command, we have the following sals:
...
(gdb) p sals
$1 = {m_array = 0x2d6b420, m_size = 2}
(gdb) p sals[0]
$2 = (symtab_and_line &) @0x2d6b420: {pspace = 0x29eb280, symtab = 0x2d4c960, symbol = 0x0, section = 0x0, 
  msymbol = 0x0, line = 1, pc = 0, end = 0, explicit_pc = false, explicit_line = true, is_stmt = false, prob = 0x0, 
  objfile = 0x0}
(gdb) p sals[1]
$3 = (symtab_and_line &) @0x2d6b478: {pspace = 0x29eb280, symtab = 0x2d4c960, symbol = 0x0, section = 0x0, 
  msymbol = 0x0, line = 1, pc = 0, end = 0, explicit_pc = false, explicit_line = true, is_stmt = false, prob = 0x0, 
  objfile = 0x0}
...

The two items are identical.

(In reply to Tom de Vries from comment #1)
> So there's the problem of repetition.

Aha.  And that's also reason for the missing line:
...
         /* If this is the only line, show the source code.  If it could                                             
             not find the file, don't do anything special.  */
          if (annotation_level > 0 && sals.size () == 1)
            annotate_source_line (sal.symtab, sal.line, 0, start_pc);
...

Tentative patch:
...
diff --git a/gdb/symtab.c b/gdb/symtab.c
index 0117a2a59d7..cfad7716cd8 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -565,6 +565,9 @@ iterate_over_some_symtabs (const char *name,
 
   for (cust = first; cust != NULL && cust != after_last; cust = cust->next)
     {
+      if (cust->user != nullptr)
+	continue;
+
       for (symtab *s : cust->filetabs ())
 	{
 	  if (compare_filenames_for_search (s->filename, name))
...

(In reply to Tom de Vries from comment #0)
> So this is a gdb 12 -> gdb 13 regression.

Bisects to commit 9ed6d7410c8 ("[gdb/symtab] Fix line number of static const class member").

(In reply to Tom de Vries from comment #4)
> (In reply to Tom de Vries from comment #0)
> > So this is a gdb 12 -> gdb 13 regression.
> 
> Bisects to commit 9ed6d7410c8 ("[gdb/symtab] Fix line number of static const
> class member").

So, it seems this is not a regression, it's just that the FAIL was hidden by  commit 6d263fe46e0 ("Avoid bad breakpoints with --gc-sections"), until it was unhidden by the commit mentioned above.

This fails as far back as gdb 8.3.

https://sourceware.org/pipermail/gdb-patches/2023-August/202069.html

The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7023b8d86c6f2403a4d7337e0b55fa9290181a06

commit 7023b8d86c6f2403a4d7337e0b55fa9290181a06
Author: Tom de Vries <tdevries@suse.de>
Date:   Wed Sep 6 10:14:50 2023 +0200

    [gdb/symtab] Handle PU in iterate_over_some_symtabs
    
    When running test-case gdb.base/setshow.exp with target board cc-with-dwz I
    run into:
    ...
    (gdb) info line 1^M
    Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
    Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
    (gdb) FAIL: gdb.base/setshow.exp: test_setshow_annotate: annotation_level 1
    ...
    while the expected output is:
    ...
    Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.
    ��setshow.c:1:0:beg:0x400527
    ...
    
    The second line of the expected output is missing due to the first line of the
    expected output being repeated, so the problem is that the "Line 1" line is
    printed twice.
    
    This happens because the PU imported by the CU reuses the filetab of the CU,
    and both the CU and PU are visited by iterate_over_some_symtabs.
    
    Fix this by skipping PUs in iterate_over_some_symtabs.
    
    Tested on x86_64-linux, target boards unix, cc-with-dwz and cc-with-dwz-m.
    
    Approved-By: Tom Tromey <tom@tromey.com>
    
    PR symtab/30797
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30797

Fixed.