I am sorry, but this proposal has been discussed and rejected already as #498.

Actually, I agree with your comment in #498, but my proposal is different in that it only includes success codes, not every code. With the same concerns:

creating and maintaining it would require a lot of work.

Not with the success codes.

Vulkan and DX12 functions are known to return error codes beyond the official list anyway

Should not be relevant if we limit the scope to success codes, right?

Whenever a specific returned value has a specific meaning (like in vmaFindMemoryTypeIndex), it is documented.

It's documented in a free form, what I propose is a strict format.

Interesting thing by the way: Vulkan-Hpp throws exceptions for error codes and VMA-Hpp currently does the same, but for vmaFindMemoryTypeIndex and similar functions, VK_ERROR_FEATURE_NOT_PRESENT is one of the normal results - it doesn't look to me like we should throw exception there. Although the result code indicates an error, semantically it's a status code.
So you've chosen the most suitable code you could find among existing codes, but did you originally consider this an error, or status code?

It seems, such confusion is a sign, that strict documentation of return codes could indeed be helpful, but if you reject my proposal, the discussion is still valuable in itself.

I am sorry but VMA is a C++ library with interface in C, while any binding to other programming languages are out of scope of this repository. To avoid feature creep, I don't want to make the code longer or more convoluted to support such bindings.

I get it, thank you. Could you answer my question about VK_ERROR_FEATURE_NOT_PRESENT, please?
Do you consider this a status or error code in the context of vmaFindMemoryTypeIndex?
I am confused because semantically it looks like a status code - a normal result for a query function to find nothing.
On the other hand, the constant itself belongs to the error group (VK_ERROR prefix & negative value).
Also, following the Vulkan spec, returning error code leaves output parameters undefined, which is indeed the case with vmaFindMemoryTypeIndex (it may either leave it unchanged, or set to UINT32_MAX), so behavior-wise it seems to lean more to the "error" group.