I see that SpliteratorTraversingAndSplittingTest tests far more collection implementations than Collection8Test does, but we now have tests that caught spliterator bugs not caught by SpliteratorTraversingAndSplittingTest. Our tests of Spliterators are often comingled with other test methods, e.g. in testIteratorEquivalence.
So, possible future work: testing could be improved in both dimensions of increasing number of implementations and increasing number of tests.
