My question is: wouldn't it be reasonable to have some configurable
threshold of gap between the lost sequence number and maximum sequence
number currently seen by the dissector, so that after this threshold
is passed the dissector gives up to reassemble the stream and feeds
the upper level dissector next packets after the lost one?
Yes, the out of order assembly doesn't work with lost packets, which is why it's off by default. There's some open issues about it on GitLab.
Your suggestion is a reasonable one, though note that some state has to be stored so that the same stream bytes are also sent to the upper level dissector in the same frame on subsequent passes and random access in the GUI. I am happy to review your MR after you submit it on GitLab.
Cheers,
John Thacker