@broot No, it is not. It is by design that in some cases these variables will never be initialized.
Think of a tree where you store the var parent and the var list of childs. The top-node will never have a parent and thus never be initialized. This is checked by parent == null. The bottom nodes do not have childs, as such also always null.
The usecase for lateinit is just a split second after object initialization, e.g. for JavaFx variables or in Android where during runtime you expect the variables to be initialized, but not as a design feature.
Ok, now I understand your case. I think there are really two separate features involved here.
First is a possibility to have a getter and a setter with different types. I think this could be pretty useful, I remember some discussions here about such feature, but I don’t know if there are any plan for it.
Second feature is that the compiler understands the property could only change from A type to B type and can make guarantees needed for smart-casting. This is more complicated than it sounds, because we need to remember properties are not fields, they can have custom behavior, they can be overridden in subtypes, etc. However, Kotlin compiler already does this e.g. for val properties - we can smart cast only if there is no custom getters and property is not open. So your case should be doable.
One note: I don’t think it should be limited to nulls. We can generalize this case to setter using a subtype of the getter.
Delegated properties can help with runtime checks, but OP basically needs a setter for List and getter for List?. Ideally, with smart cast improvements. I believe for now the best we can get are two functions instead of a property.