Inaccurate paragraph about descriptor pool exhaustion

This is the paragraph about descriptor pool exhaustion:

> Similarly, the allocation **may** fail due to lack of space if the call to `vkAllocateDescriptorSets` would cause the number of any given descriptor type to exceed the sum of all the `descriptorCount` members of each element of `VkDescriptorPoolCreateInfo::pPoolSizes` with a `member` equal to that type.

1) It does not cover what happens if that allocation succeeds. I think the pool should be allowed to fail with any kind of subsequent allocation also (even if it is within limit of its type).

2) It does not cover what happens when offending allocation(s) from "1." are freed. I think the pool should be succeeding allocations (no `VK_ERROR_OUT_OF_POOL_MEMORY`)

3) The guarantees wrt the `maxSets` and `pPoolSizes` feel weakly worded.

>If a call to `vkAllocateDescriptorSets` would cause the total number of descriptor sets allocated from the pool to exceed the value of `VkDescriptorPoolCreateInfo::maxSets` used to create `pAllocateInfo->descriptorPool`, then the allocation **may** fail due to lack of space in the descriptor pool.

This does say what happens if it does **not** exceed it.

> - `maxSets` is the maximum number of descriptor sets that **can** be allocated from the pool.

This is somewhat what I want but it is weird that it addresses Application with "can" keyword. And the "can" itself feels weak\colloquial considering the command may fail for other reasons.

4) `pname:member` references unknown parameter.