I wonder if that confusion is due to the fact that you haven't yet wrapped your head around the fact that extension functions are "just" syntactic sugar for static functions. The implicit "this" becomes the the first parameter of the static function and function parameters can be null. Now you might ask "why not use static (/first class) functions then? Because those "feel" like less ideomatic to use then extension functions or methods that are defined on the object (hirachy) itself. But understanding why the extension type can be nullable is not the same is using it on nullable types. I restrict my extension functions to non-nullable types most of the time as well. The best exception to this preference -just to see where it makes sense- is the build-in function [toString](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/to-stri...), since you want it to return "null" if you invoke it on null.

I have wrapped my head around it. I think it's confusing to the reader and creates awkward semantics.

Yeah, extension functions are one of those features that went from 'oh, this is nice' to "this is so overused it's counterproductive".

It makes reading a lot of Kotlin source quite terrible.

Lately they've been shoveling a lot of similar magical "code comes from somewhere" features into a language, slowly giving it a C++ clutter type feel.

What I mean by that is this:

   val a: SomeType? = null
   // I’m forced to null check here
   if (a != null) {
       a.someMethodOnIt()
   }
   // But I don’t have to null check here
    a.someExtensionFn()

It’s weird.