OK, now I get it. Well, my position is that reserve should be replaced by some mechanism for explicitly controlling free space at each end. Then the user can rely on the guarantee that she can do as many as [back|front]_free_capacity() push_[back|front] ops without rellocation.
So, reserve_front(), reserve_back()? I mostly get your growth/reallocation strategy as-described but I think at this point you have to start to question the purpose. With a deque-like segmented structure you could allocate multiple blocks using reserve and then assign them to the back or front depending as needed. Looking at the performance of GCC's deque implementation, you're not going to lose significant iteration performance if this is done right, asides from for large types (http://www.plflib.org/benchmarks_haswell_gcc.htm#rawperformance).