suggestion：
I'm not entirely sure if this is a good suggestion, but I believe that in MPMC or MPMCBroadCaster, a method should be added to allow users to select which internal consumer they can consume from. This is because the existing code only moves on to consume from the next DemultiplexerConsumer or BroadcasterConsumer after finishing consumption from the current one. Although this might cause some confusion for users—such as the question, "Why are there two consumer indices?"—I think it enhances flexibility for user consumption, as shown in the new code example:

   public final E fetch2(int innerDeMultiplexerConsumerIndex) {
		if(innerDeMultiplexerConsumerIndex < 0 || innerDeMultiplexerConsumerIndex > nConsumers){
			throw new RuntimeException();
		}
		if (availToFetch[innerDeMultiplexerConsumerIndex] > 0) {
			E e = consumers[innerDeMultiplexerConsumerIndex].fetch();
			needsDoneFetching[innerDeMultiplexerConsumerIndex] = true;
			if (e == null) {
			} else {
				availToFetch[innerDeMultiplexerConsumerIndex]--;
				return e;
			}
		}
		return null;
	}

question1:
In the Consumer class of MPMC or MPMCBroadCaster, if the consumer follows the normal consumption process—where the consumer first calls the availableToFetch method, and if availableToFetch returns a value greater than 0, calls the fetch method, and then after stopping calling fetch, finally calls the doneFetching method—under this process, what situation would cause the call to consumers[currConsumerIndex].fetch() in the fetch method to return null for the result E e? Or why is it necessary to add the if(e == null) check?

question2:
How does CoralQueue perform compared to other similar frameworks like Disruptor? Can it be considered a replacement for frameworks such as Disruptor?