Correction: I corrected my earlier messages to get the terminology correct. The correct terminology is multiple dispatch instead of double dispatch. Double dispatch is a way to emulate multiple dispatch. The visitor pattern is an example of double dispatch.
Unfortunately real world problems do not fit into such nice, tidy theories. There are many reasons where that does not work or violates good design.
Imagine classic cases where the visitor pattern is often used. One simple case is a list of simple shapes. You would like to support drawing those shapes on different types of displays. It would be very bad design to include the code for displaying the shape on every type of display in the shape itself. That is very low cohesion and requires changing the shape class to add support for new displays.
So this is where a visitor pattern is often used. The first requirement for applying the visitor pattern is that it requires modifying the shape classes to add support for it. If you don’t control the source for those classes you can’t modify them so are out of luck from the start.
Secondly the visitor pattern requires adding boilerplate code to every class that it is used with. That code is typically a carbon copy of the code in every class. For the shapes example it may not seem like much, but for dependency injection I have seen people with a straight face say that you just add these same X lines to every class that you want to inject which when you multiply by hundreds of classes is quite a burden.
Also the visitor pattern introduces coupling between all of the classes that you can visit. They all have to accept the visitor interface and that visitor interface has to know about all of the shape classes. To see where this can be an issue imagine if the shape classes were distributed across multiple jars. You have one jar that supports basic shapes (rectangle, oval, etc.) and another jar that supports bezier curve shapes, and another jar that has convenient shapes for regular polygons. Designing a visitor pattern to encompass all these different shapes is very difficult while allowing some of the jars to be optional.
I am not saying that Kotlin should support multiple dispatch, but just that because it doesn’t problems like what the OP asked about require explicitly doing it yourself.