"VkResult" documentation is contradictory and potentially wrong.

[Lexxaro]

The Manual Page on "VkResult" contains a very confusing statement and what I believe to be a wrong value.
The "VkResult(3) Manual Page" I'm talking about can be found at:
https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkResult.html

Under "C Specification" it is stated that:
"All successful completion codes are non-negative values." and "All runtime error codes are negative values."
There are two things of which I'm unsure if they're correct:

1. Misleading information

Aren't functions that return "VK_TIMEOUT = 2" or "VK_INCOMPLETE = 5" by definition unsuccessful? Maybe they also cannot be called runtime error codes, but calling them successful seems misleading.
It is entirely possible that I'm misunderstanding the meaning of these codes. In that case please ignore this part.

2. Wrong value?

Further down in the list of possible codes there is a code called "VK_ERROR_INCOMPATIBLE_SHADER_BINARY_EXT" this code is reportedly equal to 1000482000, a positive value. Now this seems very wrong to me. Either the value is wrong, or this code, with the word "error" in it's name, isn't considered a runtime error code but a successful completion code. (Which would be pretty contradictory.)

I have also found these issues in all other versions of the Vulkan spec found at https://registry.khronos.org/vulkan/specs
(Issue 2 only in the the specs with extensions)

Thanks for fixing this issue.

[r-potter]

For 1. you skipped a part of the description:

Successful completion codes are returned when a command needs to communicate success or status information. All successful completion codes are non-negative values.

A timeout, or an incomplete set of results, are valid and expected outputs of the API. That falls under "status information". Errors are supposed to indicate that something genuinely went wrong.

For 2. this looks like a genuine spec bug. The XML is missing a dir="-" tag on the enum definition, but it's not obvious that we can actually fix that without breaking ABI compatibility. That one will need WG discussion

[oddhack]

@Lexxaro we've kicked this around internally and the resolution is that we're going to add a new enum VK_INCOMPATIBLE_SHADER_BINARY_EXT, alias the old enum to the new enum, and describe it as a success code, not an error code, in the XML and spec. That may not be the most satisfying abstract resolution, but we can't break binary compatibility and it probably should not have been described as an error to begin with.

[oddhack]

This should be fixed in the 1.3.278 spec update, as described above.