I think I've found a bug that breaks these options processing.
(First, of course, I'd tryied to use MaxDispatchCountUserThread and it appeared that my IProvider sometimes received messages beyond the MaxDispatchCountUserThread value during one dispatch() call. Then I'd debugged how could it happen...)

The problem is in the way how the dispatchAll() method of com.refinitiv.eta.valueadd.reactor.Reactor counts the messages received.
(All line numbers are for EMA/ETA version 3.6.3.1 which are parts of RTSDK-2.0.3.L2)

Lines 5137-5139:

int bytesReadBefore = dispatchOptions.readArgs().uncompressedBytesRead();
if ((retval = performChannelRead(reactorChnl, dispatchOptions.readArgs(),
      errorInfo)) < ReactorReturnCodes.SUCCESS)

later, form line 5153:

// only increment msgCount if bytes are actually read
if ((dispatchOptions.readArgs().uncompressedBytesRead() - bytesReadBefore) > 0)
{
       msgCount++;
}

Everithing looks reasoned. But diving deeper into the com.refinitiv.eta.transport.RsslSocketChannel class (the same is true for other com.refinitiv.eta.transport.Channel implementations too), in the `public TransportBuffer read(ReadArgs readArgs, Error error)` method, in the line 1283 I see:

((ReadArgsImpl)readArgs)._uncompressedBytesRead = 0;

So, it zeroes _uncompressedBytesRead, but dispatchAll() expects it to be increased upon its old value.

So if the next message in a row is not longer it wouldn't increase msgCount, i.e. wouldn't be counted against the limit.