Currently I think that idea was very bad, given that it would be difficult to find all ranges which invalidate previous front value on popFront.
It seems, consumeFront() is attempt to implement a forward iterator on top of a range. Maybe the problem is mixing up two different abstractions.
