This issue is tricky as CoroutineScope.future ktdoc mentions this behavior:

Note that the error and cancellation semantics of future are subtly different than asListenableFuture’s.
In particular, any exception that happens in the coroutine after returned future is successfully cancelled
will be passed to the CoroutineExceptionHandler from the context. See ListenableFutureCoroutine for details.

I'd like to argue here it is not a good one and actually it means interface of ListenableFuture is incorrectly implemented by CoroutineScope.future -- ListenableFuture contract has cancel() method and it doesn't mention it can sometimes crash whole app. Due to that it fails "Liskov substitution principle" -- one can not use this specific impl of ListenableFuture instead of other ListenableFuture implementations.

To substantiate my observation this trivial code already sporadically will crash due to future behavior:

  @Test
  fun cancellation_withFailureReportingRace_crashesCoroutineScope(): Unit = runBlocking(Dispatchers.IO) {
    val innerFuture = SettableFuture.create<Unit>()
    val outerFuture = future { innerFuture.await() }

    launch { innerFuture.setException(IOException()) }
    launch { outerFuture.cancel(false) }

    // NOTE: This will sporadically crash, I'd expect the failure to be only present
    // in 'outterFuture'/'innerFuture'. I think unhandled exception in CoroutineScope
    // should not happen here.
  }

I'm aware of #2774. I decided to create new issue as it is not about cancel/cancel race, although making cancel atomic might fix both. I don't think making cancel atomic will be fully possible due to constructs such as NonCancellable, but it would fix some issues.