For those of you that were spectating regarding KEEP-87. We just submitted the proposal after getting a working prototype. KEEP-87 proposes compile time DI for Kotlin alongside extension interfaces. https://kotlinlang.slack.com/archives/C0B9K7EP2/p1555493024015100

You present a rather demonstrative case:

fun <A> fetchById(id: Int, with repository: Repository<A>): A? {
  return loadById(id) 
}

But is does not seem to have a lot of added value on top of

fun <A> Repository<A>.fetchById(id: Int): A? {
  return loadById(id) 
}

This variant requires explicit receiver in the function call-site, but on the other hand saves a lot of problems with possibly confusing dependency resolution.

There is a difference, plain extension functions are limited to a single receiver

Multiple receivers could be done via KEEP-176 without any implicit logic.

Extensions functions as they are today are effectively implicit arguments no matter what we call them. The compiler implicitly activates functions syntax over types when those functions may not be part or members of the type and passes values as arguments to functions to achieve the syntax. I think there is overlap with KEEP-176 and as we mentioned in the text we are not really married to any particular encoding. Whatever brings the abilities to group extensions for a type I think it'd be great and good for Kotlin.

Extensions functions as they are today are effectively implicit arguments no matter what we call them.

No, they are not. Extension receivers are explicit in the call site. The main difference of your proposal from KEEP-176 is the implicit context resolution. KEEP-176 forces to explicitly define all receiver objects at the call site (while you try to infer them at use site).