RFC: Should git gc/repack respect .git/refs/replace?

I recently damaged a USB drive containing an archive of a finished project.

I am able to paper over a week of missing history by using the git
replace mechanism, so that git rev-list now works as expected.

When I run git gc or git repack, I get the following:

   error: Could not read 023a1d5d3977420ba041cb556c0eee17c326aeb6
   fatal: Failed to traverse parents of commit
44d578ea81f7a90989e2ee3c676f50e3aff7071f

where 0bbded9a764d9f4c8dc27b778f70d044df65f65f is one of the missing
commits I replaced with:

   git replace 023a1d5d3977420ba041cb556c0eee17c326aeb6
238d237db9137b4eaf96f1d554bf2668729b9b93

Is this expected behaviour? I had assumed that git repack would
respect the topology implied by git replace.

Some other differences:

    git cat-file commit 023a1d5d3977420ba041cb556c0eee17c326aeb6

produces the expected output (that is the same as git cat-file commit
238d237db9137b4eaf96f1d554bf2668729b9b93), but

   git cat-file commit -t 023a1d5d3977420ba041cb556c0eee17c326aeb6

fails with:

   error: unable to find 023a1d5d3977420ba041cb556c0eee17c326aeb6
   fatal: git cat-file 023a1d5d3977420ba041cb556c0eee17c326aeb6: bad file

In my view, it seems reasonable that git repack should tolerate repos
that have replace references in them otherwise you can never recover
unused space.

Thoughts?

jon.