It looks like ZPL has its own memcpy() implementation which is a work in progress. https://github.com/zpl-c/zpl/blob/dfcb9538967f381363eaef10f9... That leads me to believe feedback is desired so assuming the author posted this as a Show HN kind of thread, here's some of what I've learned implementing that function.
It goes pretty quick on the machines I've used so far to have an indirect branch with overlapping moves. Here's what that looks like in "pure c" for gcc and clang. https://github.com/jart/cosmopolitan/blob/master/libc/str/me... memcpy is hard to implement in pure c99 because aliasing pointers to non-char types can trigger ubsan errors. With rep movsb it's a good idea to check cpuid for erms support. In that case it'll be fastest for bigger moves but is still slower for small moves. See the chart at https://justine.lol/cosmopolitan/index.html which compares various methods. Also take into consideration that if you call zpl_memcpy() the compiler doesn't know that's memcpy() so it can't perform some of its inlining magic at the call site. So if you want things like null propagation it might be better to do that as a macro.
Regarding array.c I implemented a bunch of similar routines myself and eventually chose to not worry about capacity and just call realloc every time. I'm not sure if the standard specifies this, but I'm pretty sure every realloc implementation in practice, under the hood, should track the capacity and grow it at two power sizes. So even if you're just constantly appending by one char the cost should amortize itself out to be cheap in the long run.
It is very interesting to see your carefully choosing a specific layer of abstraction to somehow find the optimize both portability and performance. I agree that C99 might not always the right choice.
BTW, I am not the ZPL author, but I collect different C libraries as a personal stash of toolkits, and thought this might be interesting to other C programmers.
Might you have a write-up or link for these, and if so might you be willing to share it?
I have been using Sean Barrett's libraries [0], as well as his curated list of other people's single-header libraries [1], and, like you, I am always on the lookout for new things to add to the collection :)