They didn't ask for std::vector, just for a vector, which in this context is any extensible array type. So that seems like a disadvantage straight away. Rust for Linux provides Vec like your userspace Rust code.
Of course, the alloc::Vec in Rust for Linux doesn't have yolo-allocation, if you want space for 615 items in your Vec you will need Vec::try_with_capacity(615) rather than Vec::with_capacity(615) because you must decide what to do if the allocation fails, and if you want to push an item you'll need to try_push(item) not just push_item) for the same reason as the Vec might be full and unable to grow.
Rust's usual promises hold up though, if I try to Vec::truncate() a Vec I need to provide a mutable reference to the Vec (&mut self) and Rust won't give me one of those while I still have outstanding references, even immutable ones, to that Vec, my code won't compile.
Though if `gmake` is assumed, there is `libcody` support that's in a patch that can do it without recursive `make` at the expense of having an unknown number of outstanding compilation processes open waiting to figure out what their topological order is at build time. I do not know what the behavior of such a solution is in the presence of import cycles or unsatisfied imports, but that's also why I prefer the "scanning" solution.
FD: CMake developer working on C++ modules support.