I don't think it's useful to write an allocator where the usable size is not constant given the size. The excess space comes from statically defined size classes or excess space from the page granularity. It seems only a very naive allocator would end up in a situation where it would have dynamic trailing capacity unusable by other allocations. I can see why the current API is not ideal for very cheap allocators, but I'm unsure about how to change it without hurting performance with jemalloc (likely to be our general purpose allocator for a *long* time).

I'll probably add this to the list of unresolved questions, because I don't think this interface needs to be stable for 1.0. We could always submit patches to jemalloc exposing a few functions more suitable to the ideal API for this trait.