An honest asymmetry we could not design away, so we surfaced it instead.
Because immutable history is a core feature, deleting text does not free space — the old versions are still referenced by the checkpoints that froze them, and that is the whole point of having checkpoints. Files are different: they are stored once and referenced, so removing one that no checkpoint has frozen genuinely reclaims its bytes.
So "delete some stuff to get under the limit" is only true for part of the data, and a user who deletes conscientiously and sees the number not move will conclude the product is broken.
What we did about it: the limit message says which action actually frees space. That is not a workaround, it is the correct handling — the constraint is real and follows from a feature people want, so the failure would have been letting someone discover it by experiment. If a limit's remedy is partial, the limit has to say so at the moment it refuses.