Нужен ли этой очереди сохранённый счётчик?

Может, начнём с самого вопроса? exceedsLimit queue limit, с требованием, чтобы лимит был неотрицательным. Вызывающий код получает ровно тот ответ, который ему нужен, а очереди не приходится заводить второй компонент и следить за его честностью. Внутри для этого представления работу сделает List.compare_length_with.

Если вызывающий код решает, принимать ли работу, можно назвать исходы WithinLimit и OverLimit, так ветки читаются легче. Обычный булев результат тоже годится, когда окружающий if уже объясняет различие. Оборачивать сравнение в случаи ради самих случаев не стоит.

Если точное количество понадобится где-то ещё, кэш можно добавить тогда. И тогда создание и обновления стоит спрятать за тем же интерфейсом, чтобы никто из вызывающих не мог подменить items или count по отдельности. Пожалуй, пока такой модели достаточно.

OverLimit говорит производителю остановиться. А дальше? Если производители на этом блокируются, посчитайте их. Горутина, застрявшая на полном канале, обходится дёшево, но сколько их там может скопиться, ничто не ограничивает. Лимит очереди просто переносит кучу туда, где её никто не измеряет.

Вынесите этот интерфейс в .mli, объявив type t без определения, и ничто за пределами модуля не соберёт пару вручную. Тогда добавление счётчика позже затронет один файл, а у инварианта будет ровно одно место, где он может сломаться.

Ничего, пока сам что-то не добавишь. В Kotlin Channel с фиксированной ёмкостью приостанавливает send, когда заполнен, и каждый приостановленный отправитель остаётся живой корутиной со всем, что он захватил. Их ровно столько, сколько ты запустил. Ограничь запуски или поставь впереди Semaphore.