> You're right, I'm apparently slow today.

No worries, I'm apparently bad today at getting my point across...

> Is that a plausible solution?

You mean, as a possible replacement of what `compact` did before? 

I think, in the first place, we must decide on those two principally different solutions:

 * A) A solution similar to the one proposed here, which is only little-invasive and basically source compatible for all users of ByteString, but which has the disadvantage of having two rope-like representations to combine either Bytes or ByteString.

 * B) A solution with only one kind of compound-type. As shown in this discussion it has the consequence, that we'll have to make incompatible changes to ByteString. If we decide for this solution we have the following possibilities:
    * B1) As discussed here, use basically this PR but get rid of ByteStrings. This, however, means we have a problem implementing `ByteString.++(ByteString): ByteString`. Either, we have to get rid of it completely (users have to use Bytes instead), or we have to compact the resulting ByteString (which is not really an option IMO because it is part of ByteString's specification to support a O(1) `++` function).
    * B2) We turn the complete type hierarchy around, remove Bytes completely, leave ByteString at the bottom, and make FileBytes a subtype of ByteString. The incompatible change would then be that 1) certain operations of ByteString could block while reading FileBytes from disk 2) the immutability invariant would be somewhat softened because bytes in files are subject to change behind the user's back. This alternative (and the resulting type-hierarchy) is basically isomorphic to the other alternative B1), however, by reusing the current names as much as possible we could impose the new solution on our users without them noticing (as long as no one uses FileBytes).