When a net is driven by multiple tristate buffer, for the "slew" value at the input of the buffers "reading" from that net, it seems to take the value from the slowest driver of the net always, rather than the value from the driver of the path being analyzed. For instance, look at this excerpt :

Fanout         Cap        Slew       Delay        Time   Description
---------------------------------------------------------------------------------------------
[...]
                      0.073909    0.000168    0.253725 ^ block[12].genblk1.tbuf_spine_ow_I[23].genblk1.cell0_I/A (sky130_fd_sc_hd__ebufn_8)
     1    0.289250    1.130828    0.881752    1.135478 ^ block[12].genblk1.tbuf_spine_ow_I[23].genblk1.cell0_I/Z (sky130_fd_sc_hd__ebufn_8)
                                                         block[0].genblk1.tbuf_spine_ow_I[23].z (net)
                      3.406518    0.065144    1.200622 ^ buf_spine_ow_I[23].genblk1.cell0_I/A (sky130_fd_sc_hd__buf_2)
     1    0.006288    0.113416    0.422576    1.623198 ^ buf_spine_ow_I[23].genblk1.cell0_I/X (sky130_fd_sc_hd__buf_2)
[...]

The output slew at the output of that

ebufn_8

is ~ 1.13 ns. But then at the next line the input slew at the

buf_2

is 3.4 ns. ( And no, there is no big resistive net or anything, looking at spice sims of that net, the output slew of the buffer is pretty much the same as the input slew of the receiver ). But on the same net I also have a very weak

ebufn_1

( in another path). And if I remove that

ebufn_1

(which is not involved at all in the path being reported here), then the 3.4 ns disappears and instead it's like 1.14 ns which is what I'd expect.