Когда компаньен используется "по делу", то всё хорошо - очень приятная фича. Проблема в том, что когда компаньён начинают испльзовать как замену статиков, то это уже не выглядит красиво — повяляется лишний уровень идентации, появляется ненужный экземпляр компаньона. Часто можно просто перетащить "статики" на верхний уровень, но это не работает если нужен доступ к приватным членам класса.

То есть хочется разделить функции именно компаньена и неймспейс?

Да, частенько нужен только неймспейс.  А сейчас "в нагрузку" прилетает еще и целый объект.

Я просто пытаюсь понять, является ли MyClass.Companion.build(): MyClass "хорошим" использованием или нет? Здесь я явно использую его как неймспейс.

Примерно понял, хотя пока я не видел это как проблему. Компаньены - очень мощная штука, потенцил которых, как мне кажется, еще не до конца реализован. Про контракты на конструкторы я уже писал

Вот пример: https://github.com/mipt-npm/dataforge-core/blob/126e59f81a134723c8717393c45e384a968ceef9/dataforge-meta/src/commonMain/kotlin/hep/dataforge/meta/descriptors/ItemDescriptor.kt#L159

По сути позволяет использовать компаньенов как фабрики, которые можно генерить в одну строчку.

Возможно проблема в том что каждая третья статья, где сравниваю джаву и  котлина, был текст типа: в джаве статики, а в котлине есть компаньён

++ на собесах тоже часто это слышу

Ну это стандартное объяснение. И я в этом месте всегда объясняю, что это не правда.

а какой потенциал у компаньеонов?  Что еще можно было бы реализовать?

Ну вот я выше писал. Компаньен может рабать как автоматическая фабрика. Довольно типичный кейс, когда у вас есть куча классов, которые надо генерить куда-нибудь в однородный список. Сейчас однородно генерить их нельзя, потому что нет возможности сделать интерфейс на конструктор. Народ делает всякой богомерзкой рефлексией (ничего не имею против рефлексией, но конкретно это ее использование - бяка). Это довольно клево решается тем, что компаньен наследует фабрику. Есть, разумеется ограничения, нужно явно эту фабрику наследовать. И еще там какие-то штуки, в которые я утыкался.

Кстат Бреслва еще по тайп классам прошелся. Я сейчас окончательно убедился, что тайп классы в хаскелевом смысле (с байндингом по типам) - не то.

мб кто пояснит: нормально что вот этот код -

coroutineScope.launch {

        terminalFacade.getBatteryLevel()
            .collect { level ->
                viewState.updateValue {
                    it.copy(terminalBatteryLevel = level)
                }
            }
 }

разврачивается в 2к+ строк байткода?

coroutineScope.launch {

        terminalFacade.getBatteryLevel()
            .collect { level ->
                viewState.updateValue {
                    it.copy(terminalBatteryLevel = level)
                }
            }
 }

там где-то есть корутины?

terminalFacade.getBatteryLevel() это Flow<Int>

Ну так они не декомпилируются нормально

похоже на правду)

раньше вообще декомпайлер подвешивало.

ну оно у меня на 4500к строк байткода остановилось)