The documentation states:

// It should return true if the connection should be removed from the pool
// It can return false if it want to see subsequent packets with Accept(), e.g. to
// see FIN-ACK, for deeper state-machine analysis.

Somewhat ambiguous comment in the reassemblydump tells the following:

What it actually means in practice, is that when connection is closed with e.g. [FIN,ACK], [ACK], [FIN,ACK], [ACK], ReassemblyComplete is called on the second [FIN,ACK] packet. If ReassemblyComplete returns true, connection will be removed from the pool. The last [ACK] will actually recreate connection again, which will become stuck in the pool forever (or until it will be flushed with FlushWithOptions).

In other words, it's kinda lose-lose scenario. No matter what you'll return from ReassemblyComplete, you'll either have original connection stuck in the pool forever, or final ACK recreating connection which will be stuck forever anyway.

I noticed it when analysing some dumps. Running StreamPool.Dump at some point gave me some connections with noticeably different activity times:

[10.66.85.2->10.65.85.1 4242->52538] c2s: created:2015-12-18 19:36:34.654147 +0000 UTC, last:2015-12-18 19:36:34.654147 +0000 UTC, s2c: created:2015-12-18 19:36:34.654147 +0000 UTC, last:2015-12-18 19:36:34.654147 +0000 UTC
[10.65.85.1->10.66.85.2 40927->4242] c2s: created:2015-12-18 19:50:22.275428 +0000 UTC, last:2015-12-18 19:50:22.275428 +0000 UTC, s2c: created:2015-12-18 19:50:22.275428 +0000 UTC, last:2015-12-18 19:50:22.275428 +0000 UTC

Notice the first connection has the same activity time in all fields. It's actually the timestamp of that last ACK packet.