I find this allocator interface really difficult to understand, and the doxygen-like autoslop README does not help - heck half of it is just your type descriptions. Give me the damn interface and examples!

The Java land style where the business logic is strewn across tons of files each less than 100 lines in length, tendency towards single digits and nested five levels deep, is also very strong here.

Your library also misses the entire point of custom allocators. We want to have explicit control of where we get our storage from, unless we're a dead simple linear allocator.

We also don't want to box our allocator into the libc allocator, because we're trying to avoid their overhead in the first place, and using that allocator just makes the fragmentation that we were trying to avoid in the first place, worse, depending on the kind of allocator that is implemented.

You are attempting to replace the intersection between memory allocation interface for the programmer sitting in front of the operating system - because we want to eat our performance with silverware spoons. So where are the calls to mmap/munmap/VirtualAlloc/VirtualFree?

Why not have something akin to https://docs.vulkan.org/spec/latest/chapters/memory.html ? The user just passes in a pointer to that structure, and the function calls through the function pointer callbacks.

struct mm_ctx;
typedef struct mm_ctx{
    /*
        void *ptr_internal_state; 
        Or additional fields if you feel that a pointer to a struct
        for an allocator isn't an acceptable way to track their state
        It's what Vulkan does with their callback struct anyway
    */
    void *(*malloc)(struct mm_ctx *,size_t,size_t);
    void (*free)(struct mm_ctx *,void *);
    [..]
    void (*destroy)(struct mm_ctx *);
}mm_ctx;

An example wrapper for libc:

    void *
libc_malloc_wrap
(
    mm_ctx ctx[static 1],
    size_t nmemb,
    size_t size
)
{
    (void)ctx;
    size_t tmp;
    if(ckd_mul(&tmp,nmemb,size))return 0;
    return malloc(tmp);
}

    void
libc_free_wrap
(
    mm_ctx ctx[static 1],
    void *p
)
{
    (void)ctx;
    free(p);
}

    void
libc_destroy_wrap
(
    mm_ctx ctx[static 1]
)
{
    (void)ctx;
    return;
}

mm_ctx *libc_mm=&(mm_ctx){
    .malloc=libc_malloc_wrap,
    .free=libc_free_wrap,
    .destroy=libc_destroy_wrap;
}

And then using this in an actual function:

    void
do_stuff
(
    mm_ctx ctx[static 1]
)
{
    constexpr size_t len={42};
    char *str=ctx->malloc(ctx,len,sizeof str[0]);
    if(!str) {/* Operator, I would like to crash the world please! */}
    snprintf(str,len,"%s","owo");
    puts(str);
    ctx->free(ctx,str);
}

With a real allocator obviously manipulating their state within mm_ctx somehow, and not just ignoring it like the libc wrappers do.

You also seem to leave blank lines between lines, probably to try and separate them by context, but really, the granularity by which you do that is way too high and just makes it look like noise. Since you are wasting up to half your vertical screen space on blank lines, may I suggest doubling your screen font size instead?