problem

It seems that similar issues were raised in the past, but I feel I'm not convinced enough to agree.

1. It seems (from @smaldini words from Better names for onNextDropped vs doOnDiscard hooks, compose/transform, doOnEach #1381) that onNextDropped is a spec violation which is incorrect.

   1. Let's consider FluxTake. It does take N elements, cancel subscription upon receiving the expected number of elements to take, and set the state to done. It means that in the case of racing between CANCEL and ON_NEXT more signals can appear (imaging .cancelOn up the stream which delays a little bit cancellation) which leads that few elements can be dropped easily (which is absolutely valid case due to 2.8).
   2. In the reactor, we are over protective so all the way we double-check different flags (either cancel or done) to ensure we are not sending something extra and dropping redundant.
   3. Taking into account everything said above, onNextDropped IS DESIGNED TO HANDLE unexpected along with racing between cancellation and onNext signals.

2. Now we have another operator to handle filtered (discarded) elements on the level of the local stream, BUT it has significant design FLAW:

   1. Hooks are localized, so the discarded element is consumed only if the hook is present.
   2. It is SUPER expensive in terms of performance when it comes to Mono(or even from flux perspective) where we constantly have 3-4 objects overhead (FluxContextStart + ContextStartSubscriber + Consumer<? super R> discardHook + created Context) is WAY expensive (💔)

proposal

The only way to make it consistent is to merge both drop and discard APIs and make them interconnected, e.g if no local hooks discard hooks installed, we are free to lookup for global hooks. Since Operators.onNextDrop is, let's call it, internal API, I don't see any problem to UNIFY that in 3.4