I think, I finally found a way to demonstrate the issue. In the following memrem is a function, which just greedy requests memory until it is exhausted. Since SoftReference}}s are guaranteed to be cleared before an {{OutOfMemoryError is thrown, we can use this to check whether a reference to an item is retained.
We place a large array in a SoftReference and call partition-by such, that the array is referenced by the first group. Then we take the rest of the output sequence. Since no reference to the sequence head is retained the array should be now free for garbage collection.
However, after the memrem the SoftReference still references the array, which means there is another reference to the array. And in fact, if we actually realise the rest, this reference is gone. And after another memrem round trip the SoftReference is cleared.
The problem is that the call to drop in partition-by is not realised immediately. Hence it keeps a reference to the head of the input sequence until it is realised. However there is no reason why the drop should not immediately be realised. count is eager and hence realises the run, which in turn realises further items of the input sequence. So the elements are realised anyway. Adding a call to seq to realise the drop hence does not harm laziness of partition-by, but removes the undesired reference to the head of the input sequence. (Alternatively one could use nthnext instead of (seq (drop...)).
Note, how the SoftReference is already cleared already after call to rest.
Defect
Closed
Minor
Fix for partition-by by realising the drop.