Ой какой не факт, особенно если не было reserve

А reserve тут ни при чем, код push_back то, останется тем же.

Попробуй начать с того, почему move ctor не мог это сделать, может там рядом ответ

Конечно, я и своими силами ответ ищу, но, может в сообществе кто знает уже ответ. Хотя с мувом, все весьма очевидно. Ему разве надо что-то выделять?

А reserve тут ни при чем, код push_back то, останется тем же.

ты слышал про polymorphic memory resource? (оффтоп слегка)

Полиморфик Аллокатор? Про него, да.

про который что можно на стеке память зарезервировать и потом сделать аллокатор который будет со стэка аллоцировать

Да, слышал про такое. Но никогда не стоит забывать, что стековая память, это, условно говоря, таже хипа. Адресное пространство то одно.

ну разница в аллокации (поиск по фрилисту, против инкремента пойнтера)?

Если ты думаешь, что создав массив и сразу к нему обратившись, решает, то отмечу, что и с хипой такой трюк провернуть можно. Заранее что то там навыделять и прогреть pf ом.

Я так понимаю, по итогу, не имея возможности заранее задавать буффер, мы получаем деградацию перфоманса, пусть и маленькую: когда начальный размер нуль, в push_back мы должны будем сделать проверку и выставить нужный размер - если нуль, то скажем, 4 элемента, а если не нуль, то умножим на два, как и делает gcc...Но это лишняя инструкция, в лучшем случае - cmove, если мы про x86, в худшем - ветка, наверное. Или такой гарантии нету и все же мы можем дёрнуть аллокатор в конструкторе вектора, при этом как то порешав проблемы с noexcept spec?(которая по утверждению cppref берется с Умолчательного ctor allocator, а не у функции allocate!!!)