Yes, you can achieve also reduce local readability by passing objects containing buckets of state around. But such classes always smell to me - particularly if

Yes, you can achieve also reduce local readability by passing objects containing buckets of state around. But such classes always smell to me - particularly if component instances have other aliases. But I try to avoid it by designing distinct and hopefully coherent service or context classes. And this Kotlin feature effectively requires you structure your context/service/etc. classes in this way - the point is to allow multiple implicit contexts. When you say 'action-at-a-distance' - I would argue that the "distance" is not on the same scale. One crosses statements invisibly while your example, in all languages I've used, would still constitute a single statement. But fundamentally, this is an argument about style as it's not a pure binary distinction, so I don't think there's a definitive right or wrong here. Subjectively - in my experience, codebases (remembering one in Scala in particular) which rely heavily on implicit context objects are more difficult to understand. For me, when trying to get my head around an unfamiliar codebase, explicit is better than implicit unless it introduces so much verbiage that the intent is hidden.