interrupting `shred -u's renaming: what should it do?

[Jim Meyering]

Here's a little question:

  If shred is interrupted while repeatedly renaming a file,
  should it remove the file?

For those who haven't run `shred -u' with the --verbose,
here's some output demonstrating the renamings it performs
in an attempt to scribble on the original name in the directory entry:

  $ : > private
  $ shred -u --verbose --iterations=0 private
  shred: private: removing
  shred: private: renamed to 0000000
  shred: 0000000: renamed to 000000
  shred: 000000: renamed to 00000
  shred: 00000: renamed to 0000
  shred: 0000: renamed to 000
  shred: 000: renamed to 00
  shred: 00: renamed to 0
  shred: private: removed

My first reaction was that it's obvious:
Such an intermediate-named file should be removed.
But the goal of shred is to obfuscate and remove,
so a signal like SIGINT may indicate that someone
has decided they don't want to complete the task.
On the other hand, is it appropriate to leave behind
an obscurely-named file like one of the `0..00' ones above?

I'm leaning toward a compromise: have shred issue a warning
with the name of any file it leaves behind.

Comments welcome.