Eli's idea of adding -fno-tree-sra to the build options for the next
build is a good one.

Yes, thanks to both for the suggestion! I will make a build with this option and see if the bug persists.

Could it also be a dynamic module responsible? I am running at least a few of these (tree-sitter https://github.com/emacs-tree-sitter/elisp-tree-sitter, vterm https://github.com/akermu/emacs-libvterm and pdf-tools https://github.com/vedang/pdf-tools, maybe a few more).

Here are the gdb things:

Now we have the other bug, though, it would be interesting again. Maybe
the same thing happened to a nativecomp constant vector here as happened
to a bytecode closure's constant vector in the new crash. Do you still
have the old core file, and can you run x/32gx 0x98e7980?

Yes, here it is:

(gdb) x/32gx 0x98e7980

0x98e7980: 0xc00000001a003007 0x0000000008f680f4
0x98e7990: 0x000000001f647ac3 0x00000000098e79dd
0x98e79a0: 0x00000000098e7a25 0x0000000000000000
0x98e79b0: 0x00000000098e7d75 0x00000000098ee6cd
0x98e79c0: 0x00001555338a2ec0 0x0000000000000000
0x98e79d0: 0x000000001cbc0740 0xc00000000e008000
0x98e79e0: 0x0000000020e10970 0x0000000003aa20d0
0x98e79f0: 0x0000000003aa1ac0 0x00000000006e9960
0x98e7a00: 0x000000002265f480 0x0000001a0000001a
0x98e7a10: 0x0000400700000060 0x0000000000000000
0x98e7a20: 0x400000000e008000 0x000000001bfdbe90
0x98e7a30: 0x0000000020e10b80 0x000000001bfdb880
0x98e7a40: 0x00000000006e98e0 0x000000001fd792e0
0x98e7a50: 0x0000001a0000001a 0x0000400700000060
0x98e7a60: 0x0000000000000000 0x400000001f000005

0x98e7a70: 0x0000000000000606 0x0000000008ae5654

Oh, sorry, "p *(struct Lisp_String *)0x000000001cfbfe40".

(gdb) p *(struct Lisp_String *)0x000000001cfbfe40
$20 = {u = {s = {size = -9223372036854775719, size_byte = -1, intervals = 0x0, data = 0x18c4d720 "/u/panagopo/.config/emacs/.local/cache/eln/30.1-1ed0c1e8/lsp-erlang-9f1a9a34-b13245d7.eln"}, next = 0x8000000000000059,
gcaligned = 89 'Y'}}