Suricata

frag-5 is not an evasion for me :
We have a valid reassembly of 3 fragments, for an ICMPV6 ping
then the reply
Then a replay of one of the fragments (but Suricata must have forgotten it and interprets it as a new reassembly to do)

frag-13 is not an evasion for me.
It is simply a big reassembly leading to a payload of 65494 bytes
RFC2460 states

If the length and offset of a fragment are such that the Payload

The pcap is below that limit of 65535, which is implemented in Suricata cf IPV6_FRAG_PKT_TOO_LARGE

Zeek however uses 64000 cf https://github.com/zeek/zeek/blob/5d38bb029a45c28e01fe55c9734b7b58d3d0e1fa/src/Frag.cc#L14
And the name is misleading as all fragments have a size of 1232 bytes, it is their reassembly that exceeds 64000 bytes

frag-14 is the same as frag-13

frag-19 is simply a fragment without another to end reassembly...

The PR https://github.com/OISF/suricata/pull/6367 solves the case ipv6-malformed-fragments-8 where we have

mf true frag_offset 0 data_offset 62, data_len 408, frag_end 408, ip_hdr_offset 14, frag_hdr_offset 54
mf false frag_offset 808 data_offset 62, data_len 400, frag_end 1208, ip_hdr_offset 14, frag_hdr_offset 54
mf true frag_offset 408 data_offset 62, data_len 528, frag_end 936, ip_hdr_offset 14, frag_hdr_offset 54

and no overlap is given when last fragment [408:936] overlaps with previous one [808:1208]