We talked about it a lot. It seems inevitable that we'll end up with many different types in the design space of arrays. When you need tight control over allocation and per-operation costs — whether you're writing an embedded system or just doing very careful performance work — general-purpose data structures usually need to give way to more specialized designs. We may end up with ten or more array types across the standard library and other core libraries. Hopefully, most programmers will never need to use anything besides Array, because Array will serve their needs just fine. Other programmers may need to be conversant with most or all of them.
We will not end up with some completely consistent, taxonomic naming system for all those types. If nothing else, Array will always sit outside that system: it has key implementation characteristics that will never be reflected in its name because we are not going to rename it to ShareableDynamicArray as would befit its role in the taxonomy. Moreover, predicting what characteristics are important to call out in the name is a losing game: if we did have a type named ShareableDynamicArray, what would happen in five years when we realize that we need a second shareable dynamic array type with different characteristics along a new dimension? And besides, names like these are awful: they're long, they're pedantic, and they're unapproachable for new users.
In my opinion, it is better to pick distinctive names that evoke the role of the type, and it's fine for more specialized types to have more complex names as a rough proxy for how unlikely it is that someone will need to use it. So I am not worried that we will box ourselves into a corner here. If we find that we need a fixed-capacity, dynamically-sized array with inline storage, this name will be taken, and we will have to find a different name for the new type that seems to adequately distinguish it. But that will be quite a specialized type, and it might have rather specialized operations to go with it (e.g. we might want append to fail recoverably rather than with a precondition trap); I do not think people will be casually reaching for it.