Does a cancelled REINDEX CONCURRENTLY need to be messy?

Hi,

It's documented that a failed REINDEX can leave behind a transient
index, and I'm not going to speculate on all the conditions that could
lead to this situation. However, cancelling a REINDEX CONCURRENTLY
will reliably leave behind the index it was building (<index
name>_ccnew).

Doesn't a cancellation instruct the process that the user has made a
decision regarding the fate of the new version of the index? Is there
a situation where the incomplete transient index might need to be
inspected following a cancellation?

Because if not, why not get it to tidy up after itself? If the
process crashed, fair enough, but it just doesn't sit well that
leftover artifacts of an aborted operation aren't tidied up,
especially since subsequent attempts to REINDEX will find these
invalid transient versions and attempt to REINDEX them. Why should
the user need to know about them and take manual action in the case of
a cancellation?

I get the feeling that this is deliberate, and perhaps an attempt to
mitigate locking issues, or some other explanation, but the rationale
isn't immediately apparent to me if this is the case.

Thanks

Thom