I think the intent of alloca in Posix and VLA in C was specifically to have automatic cleanup semantics for objects with block scoped lifetime. C++ already has the language feature that makes it possible to ensure proper cleanup at end of scope, so the need for VLA evaporates. If you look closely, the C language doesn't seem to make any mention of the stack in the specification of VLAs, I think a pair of malloc/free may be a possible implementation.

Neither C or C++ seem to formally require that implementation use a stack for automatic allocations. alloca do mention a stack, but it is specific to POSIX, not strictly standard C. IMO,  If C had a requirement that automatic allocations be done on a stack, then I think alloca would be part of standard C, and VLAs would never have existed

On August 14, 2023 2:43:35 p.m. EDT, Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Mon, Aug 14, 2023 at 4:21 PM Thiago Macieira <thiago@macieira.org> wrote:

And what would such function be used for? Please give three different use-cases
or at least one very strong one that couldn't otherwise be implemented without

On Page 6 of my paper on Named Return Value Optimisation:

I place a UUID on the stack alongside data which is to be retrieved
later. Basically it's a universal way of implementing thread-local
storage. So if I want to have a thread_local variable called 'abc',
then my strategy is that at every thread entry point, I place the UUID
on the stack beside the four bytes 'a' 'b' 'c' '\0' followed by the
bytes denoting its value. Then later in the program's execution I can
walk the stack backwards til I find the UUID and then I have access to
my thread-local data.

I can use the function "alloca" at runtime to create more thread-local

But more to the point: We should have control of stuff in C++. Every
C++ platform has a stack, so give us access to it. Just because I can
only come up with one good use for it now doesn't mean someone else
won't come up with a use for it later.