Just wondering if it would help to have the third kind of object representation in the object database, sitting next to loose objects and packed objects, say .git/objects/verbatim/<hex-object-name> for the contents and .git/objects/verbatim/<hex-object-name>.type that records "blob", "tree", "commit", or "tag" (in practice, I would expect huge "blob" objects would be the only ones that use this mechanism). The contents will be stored verbatim without compression and without any object header (i.e., the usual "<type> <length>\0") and the file could be "ln"ed (or "cow"ed if the underlying filesystem allows it) to materialize it in the working tree if needed. "fsck" needs to be told about how to verify them. Create the object header in-core and hash that, followed by the contents of that file, and make sure the result matches the <hex-object-name> part of the filename, or something like that.
