Return to Answer

Instead of parsing an Int with the catch (e: NumberFormatException) { ... }, consider using the String.toIntOrNull() extension:

 val x = readLine().toIntOrNull() ?: run {
 println("You didn't type a valid number.")
 return
 }

In Kotlin extension functions, reference the members of the receiver type without explicit this: this.size → size unless the name is ambigous.

Instead of (0 until this.size / 2).map { this.elementAt(it) }, you could just use take(size / 2) (but see below why you should not).

The approach you take to check in which half the item can be located and move the binary search window to a half of the list (by copying or removing the first half) changes the run time of the algorithm significantly: while binary search should take O(log n) time to find an element, your implementation additionally performs O(n/2 + n/4 + n/8 + ...) = O(n) operations checking the first half and then copying or removing the items, making the search asymptotically as slow as serial search through the list. Consider checking only the item in the middle of the list (the assumption that the list is sorted allows you to do that) and then using .subList(...) to get a view of a portion of the original list, in O(1) time.

Instead of parsing an Int with the catch (e: NumberFormatException) { ... }, consider using the String.toIntOrNull() extension:

 val x = readLine().toIntOrNull() ?: run {
 println("You didn't type a valid number.")
 return
 }

In Kotlin extension functions, reference the members of the receiver type without explicit this: this.size → size unless the name is ambigous.

Instead of (0 until this.size / 2).map { this.elementAt(it) }, you could just use take(size / 2) (but see below why you should not).

The approach you take to check in which half the item can be located and move the binary search window to a half of the list (by copying or removing the first half) changes the run time of the algorithm significantly: while binary search should take \$ O(log n) \$ time to find an element, your implementation additionally performs \$ O(n/2 + n/4 + n/8 + ...) = O(n) \$ operations checking the first half and then copying or removing the items, making the search asymptotically as slow as serial search through the list. Consider checking only the item in the middle of the list (the assumption that the list is sorted allows you to do that) and then using .subList(...) to get a view of a portion of the original list, in \$ O(1) \$ time.