How complex is your renderer? It's not that hard to do memory management manually with Vulkan for simple rendering pipelines. I think it gets harder when you want to have a lot of dynamism going on.
VMA doesn't solve a lot of hard problems around memory management, which really come from synchronization issues. You need to make sure that the GPU is done with a resource before you can destroy it on the CPU side. What it brings is a host of allocation algorithms for very specific use cases and a lot of code for tracing/debugging memory usage. Plus, it shields the users from some positively braindead quirks that the Vulkan spec has gathered (some through extensions that create traps when they aren't enabled - just present; I had to scream when I pieced that together...).
I have my own slightly anemic memory manager code that implements a basic scheme with no frills, avoids pitfalls and fits into about 500 lines of code. The only thing I really might want to improve is the some of the free lost handling. The rest shoukd be good for quite a while.
Yeah I don't even really have a system for this; I basically have the mostly statically managed memory which is living for the length of the scene/program, and for per-frame stuff I just wait for fences on a cleanup thread.
It's a somewhat general 3D API wrapper which exposes an API that's similar to Metal and WebGPU, but with a number of restrictions because it needs to support GLES2/WebGL backends as the worst case).
One idea I'm playing with is to provide callback hooks so that resource allocation and management can be delegated to the API user (so they can for instance integrate VMA themselves), and only provide a rudimentary default solution (which probably would be enough for many simple use cases).
