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 exactly 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 WithinLimit and OverLimit might make the branches easier to read. 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. That may be enough modeling for now.

OverLimit tells a producer to stop. Then what? If producers block on it, count them. 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.

Nothing, unless you add something. In Kotlin 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.