This seems to fail in the second call to V3LinkDot, after initial elaboration. At that point the if signed test is not need, so try adding an additional test "if (nodep->getChildDTypep() && ...)". If that works (or if you find another fix) please submit a pull request with the fix and a test case, thanks for debugging.

I think I've identified the problem better (i've modified the example program). It seems that when the function result is assigned to a parameter or localparam, it will duplicate the enum_next variable in the AST as such:

src/obj_dir/Vt_enum_const_methods_017_const.tree
    1: PACKAGE 0x555557970c60 <e1117> {a0aa}  __024unit  L0 [LIB] [NONE]
    1:2: VAR 0x5555579b0300 <e975> {d9am} @dt=0x5555579d9e10@(w1)u[1:0]  __Venumtab_enum_next0 [CONST] MODULETEMP
    1:2:3: INITARRAY 0x5555579dc800 <e976> {d9am} @dt=0x5555579d9e10@(w1)u[1:0] [0]=0x5555579da8f0 [1]=0x5555579da9a0
    1:2:3:1: CONST 0x5555579dc900 <e1489> {d9am} @dt=0x5555579d8d00@(G/w1)  1'h0
    1:2:3:2: INITITEM 0x5555579da8f0 <e986> {d9am}
    1:2:3:2:1: CONST 0x5555579dca00 <e1490> {d9bc} @dt=0x5555579d8d00@(G/w1)  1'h1
    1:2:3:2: INITITEM 0x5555579da9a0 <e990> {d9am}
    1:2:3:2:1: CONST 0x5555579dcb00 <e1491> {d9ay} @dt=0x5555579d8d00@(G/w1)  1'h0
    1:2: VAR 0x5555579b0480 <e1249> {d9am} @dt=0x5555579a15f0@(w1)u[1:0]  __Venumtab_enum_next0 [CONST] MODULETEMP
    1:2:3: INITARRAY 0x5555579dd000 <e1248> {d9am} @dt=0x5555579a15f0@(w1)u[1:0] [0]=0x5555579db130 [1]=0x5555579db1e0
    1:2:3:1: CONST 0x5555579ddd00 <e1492> {d9am} @dt=0x5555579d8d00@(G/w1)  1'h0
    1:2:3:2: INITITEM 0x5555579db130 <e1257> {d9am}
    1:2:3:2:1: CONST 0x5555579a2000 <e1258> {d9bc} @dt=0x55555797ce10@(w1)enum  1'h1
    1:2:3:2: INITITEM 0x5555579db1e0 <e1261> {d9am}
    1:2:3:2:1: CONST 0x5555579ddf00 <e1260> {d9ay} @dt=0x55555797ce10@(w1)enum  1'h0
    3: TYPETABLE 0x555557978000 <e2> {a0aa}

The nodep that gives a nullptr getChildDTypep is the second one which doesn't exist when the two param assignments from my above example are commented and uncommented respectively. This duplicated variable appears to be added between the tree dump for the files src/obj_dir/Vt_enum_const_methods_009_linkdotparam.tree and src/obj_dir/Vt_enum_const_methods_011_width.tree.

src/obj_dir/Vt_enum_const_methods_009_linkdotparam.tree
    1: PACKAGE 0x555557970c60 <e1117#> {a0aa}  __024unit  L0 [LIB] [NONE]
    1:2: VAR 0x5555579b0300 <e975#> {d9am} @dt=0x5555579d9e10@(w1)u[1:0]  __Venumtab_enum_next0 [CONST] MODULETEMP
    1:2:3: INITARRAY 0x5555579dc800 <e976#> {d9am} @dt=0x5555579d9e10@(w1)u[1:0] [0]=0x5555579da8f0 [1]=0x5555579da9a0
    1:2:3:1: CONST 0x5555579dc900 <e985#> {d9am} @dt=0x555557980f70@(G/w1)  1'h0
    1:2:3:2: INITITEM 0x5555579da8f0 <e986#> {d9am}
    1:2:3:2:1: CONST 0x5555579dca00 <e987#> {d9bc} @dt=0x555557980f70@(G/w1)  1'h1
    1:2:3:2: INITITEM 0x5555579da9a0 <e990#> {d9am}
    1:2:3:2:1: CONST 0x5555579dcb00 <e989#> {d9ay} @dt=0x555557980f70@(G/w1)  1'h0
    3: TYPETABLE 0x555557978000 <e2> {a0aa}

The next thing I think I should do is stop the ast from duplicating this variable and then make sure that the function that tried to use it pulls enum_next from the existing var.

I tried analyzing the AST tree that comes out from when I add "if (nodep->getChildDTypep() && ...)" and what happens is that the duplicated VAR 0x5555579b0480 is removed from the tree but is still referenced by:
VARREF 0x555557970ea0 <e1287> {d9am} @dt=0x555557a695f0@(w1)u[1:0] __Venumtab_enum_next0 pkg=0x555557970c60 [RV] <- VAR 0x5555579a6480 <e1545#> {d9am} @dt=0x555557a695f0@(w1)u[1:0] __Venumtab_enum_next0 [CONST] MODULETEMP
Is this variable supposed to be removed or is the VARREF supposed to be updated to point to the original enum value (0x5555579b0300 )?

Update:
I used gdb to substitute the original varp in the varref which then lets the compilation complete normally

It shouldn't have gotten duplicated, especially not with an identical name, so that's one problem. I think the enum being referred to needs to be in the dtype table once it is referred to, so if that type goes away the function can still refer to it.

Alternatively we'd somehow track which of these variables gets deleted if a enum data type gets deleted, but that seems a lot of new work to do.

Full fix including this merged manually.