Does this queue need a cached count?

Could we start with the question itself? exceedsLimit queue limit, with the limit required to be nonnegative. The caller gets the answer it asks for, and the queue doesn't grow a second component that has to be kept honest. Underneath, List.compare_length_with does the work for this representation.

Where the caller is deciding whether to admit work, naming the outcomes might make the branches easier to read.

type admission = WithinLimit | OverLimit

let admit items limit =
  if List.compare_length_with items limit > 0
  then OverLimit
  else WithinLimit

A plain boolean is fine too when the surrounding if already says what the distinction means. Wrapping a comparison in cases for its own sake isn't worth it.

If exact counts turn out to be useful elsewhere, the cache can come then. When it does, construction and updates should sit behind the same interface, so no caller can replace items or count on its own. Until somebody asks for the number, I'd leave it out.

OverLimit tells a producer to stop. Then what? If producers block on it, count them. I see this most in Go, where a goroutine parked on a full channel is cheap, but nothing caps how many can park there, so the queue's limit just moves the pile somewhere nobody is measuring.

Put that interface in the .mli, with type t declared and no definition, and nothing outside the module can build the pair by hand. Adding the count later is then a change to one file, and the invariant has exactly one place where it can break.

Same in Kotlin, nothing caps it unless you add something. A Channel with a fixed capacity suspends send when it is full, and every suspended sender is still a live coroutine holding whatever it captured. Their number is just how many you launched. Bound the launches, or put a Semaphore in front.