Wait, how is Box<T> now any bigger than *T? The Global allocator is a ZST, and presumably any alternative allocator would strive to be too. The associated typetype parameter A, constrained on implementing AllocRef and set by default to Global is (so far) purely type level information that gets compiled away. I would expect that the only case where a custom allocator would incur a runtime cost would be if they want to enable multiple independent instances of the allocator (which I would think is a bad idea for multiple reasons).
This is a good point and a shame that things have gotten more verbose for library writers that desire to be as generic as possible, but this seems to be no different than the burden that libraries already have if they want to support ?Sized fields or no_std environments, while enabling an entirely new level of customization for Rust libraries.
I also think that this is something that we could handle at the language level somehow to benefit not only the new Box defaulted type parameter, but all types that might have them (in the same way that improving things impl Trait or associated types can be driven by async/await use cases but also benefits others too).
But other allocators don't have to be. This is now a problem e.g. in FFI, because even though the majority of allocators may be ZST, one can no longer rely on this fact.
How is this even comparable? If you want to support ?Sized, you have to make special considerations anyway, and also the code doesn't break silently. Adding a type parameter to Box, however, does silently break code, because impl<T> Trait for Box<T> no longer means "implement Trait for all boxes", it now means "implement Trait for boxes using the global allocator", which, with overwhelming probability, is not what the implementor's
intent was.