A DESCRIPTION OF THE PROBLEM :
Gatherer has a lot of implementation requirements. However, some of them are neither enforced nor clearly documented in the Javadoc.

This results in a proliferation of non-compliant implementations, a.o., through libraries of Gatherer implementations.

For example, a Gatherer must be reusable. However, Gathering implementations that have a Stream/Iterator/Spliterator/... parameter, typically consume the argument lazily and are not reusable. Some use cases are concatenating, zipping, and interleaving two streams.

For zipping, https://bugs.openjdk.org/browse/JDK-8015316 was closed under the assumption that this could be done with Gatherers.

For operations that must work with any given two streams, possibly both having an infinite number of elements:

* either the Gatherer specification must be clarified to rule out non-reusable implementations, the Stream pipeline code should make non-reusable implementations fail (e.g., by invoking Gatherer methods twice, discarding the result of the first invocation. Cf. `ConcurrentModificationException`), and the Stream API must provide methods for such operations (e.g., `Stream::concat` already exists for concatenation, and `Stream::zip` should be added for zipping, as requested by the above JBS issue)
* or the Gatherer specification must be relaxed to allow non-reusable implementations (maybe providing a method `boolean consumable()`, which would return `false` for non-reusable Gatherers that have already been used)