blocking v2 client stub inconsistent about StatusRuntimeException verus StatusException

[benjaminp]

io.grpc.stub.BlockingClientCall uses the checked StatusException, so server-streaming and client-streaming v2 blocking RPCs have to deal with StatusException. However, the unary blocking v2 RPCs stubs have the implementation and thus behavior as v1; namely, all status exceptions are StatusRuntimeException. Should this be made consistent?

[kannanjgithub]

The reason that we started using the checked exception is that we want to start moving in general to StatusException rather than StatusRuntimeException and the read/write methods in the BlockingClientCall already had other checked exceptions so it wasn't making things easier on the user if the status was unchecked.
ClientCalls and the old blocking stub are stable so we can't change from StatusRuntimeException to a checked exception even if we wanted to since we can't break existing code. The only way we could have the checked StatusException be thrown by unary blocking RPCs to to introduce new wrapper methods in BlockingClientCall that would catch and convert StatusRuntimeException to StatusException, however it doesn't appear like this is necessarily what you want.

[benjaminp]

I'm just curious why this "blocking v2" interface is inconsistent. If the goal is to move to StatusException in general, why not make all blocking methods on the new interface throw the checked StatusException? Whether that requires adding new wrappers or not seems like an implementation detail.