A couple thoughts on this issue:

First, I think the OP's original issue could perhaps largely be addressed without having to change cancel()'s signature. Namely, simply passing a hard-coded string to CancelledError in the couple spots that CancelledError is raised would cause the exception to display:

https://github.com/python/cpython/blob/733d0f63c562090a2b840859b96028d6ec0a4803/Lib/asyncio/futures.py#L153
https://github.com/python/cpython/blob/733d0f63c562090a2b840859b96028d6ec0a4803/Lib/asyncio/futures.py#L173

The "raise CancelledError" could be changed to "raise CancelledError('future is cancelled')", a bit like how InvalidStateError is handled a couple lines later:

    if self._state == _CANCELLED:
        raise CancelledError
    if self._state != _FINISHED:
        raise InvalidStateError('Result is not ready.')

Second, in terms of making cancellations easier to debug, is it a deliberate design decision that the CancelledError traceback "swallows" / doesn't show the point at which the coroutine was cancelled?

For example, running the following code--

    async def run():
        await asyncio.sleep(1000000)

    loop = asyncio.new_event_loop()
    task = asyncio.ensure_future(run(), loop=loop)
    loop.call_later(2, task.cancel)
    loop.run_until_complete(task)

Results in the following output:

    Traceback (most recent call last):
      File "test-cancel.py", line 46, in <module>
        loop.run_until_complete(task)
      File "/Users/.../python3.6/asyncio/base_events.py", line 466,
          in run_until_complete
        return future.result()
    concurrent.futures._base.CancelledError

In particular, it doesn't show that the task was waiting on asyncio.sleep(1000000) when the task was cancelled. It would be very useful to see full tracebacks in these cases. (Sorry in advance if this second point is off-topic for this issue.)