FYI - we are in process of abandoning internal MR 5593 in preference to 5596, which introduces a new type for the PFN. So the fix in #1463, while still appropriate, isn't immediately required. Would appreciate feedback on internal MR 5596 however.

That is, #1463 isn't needed at all? I'll close it then. It would just introduce unneeded complexity.
Besides that, I think, using an attribute for something like "name" seems to be more appropriate to me than a tag name (or an element). After all, there's supposed to be exactly one "name" per thing, and that name should probably not contain any other information. But, of course, that should be the standard, not the exception. Just my opinion.
Just replacing <PFN_vkGetInstanceProcAddr> by <PFN_vkGetInstanceProcAddrLUNARG> would seamlessly work with the generator, but would break all code that's explicitly using <PFN_vkGetInstanceProcAddr>!

That is, #1463 isn't needed at all? I'll close it then. It would just introduce unneeded complexity. Besides that, I think, using an attribute for something like "name" seems to be more appropriate to me than a tag name (or an element). After all, there's supposed to be exactly one "name" per thing, and that name should probably not contain any other information. But, of course, that should be the standard, not the exception. Just my opinion.

It may be needed in the future, because this is part of the schema. In general we use <name> tags because the name has to be part of the tag content in any event, and having e.g. <type name="VkFoo">...typedef void VkFoo;</type> is redundant and error-prone - but there are occasional cases where a tag needs a name, so it can be used as a dependency, yet the name isn't needed in the tag content (usually something like external header dependencies which define types).

Just replacing <PFN_vkGetInstanceProcAddr> by <PFN_vkGetInstanceProcAddrLUNARG> would seamlessly work with the generator, but would break all code that's explicitly using <PFN_vkGetInstanceProcAddr>!

That is in fact what we did, but I don't think it's going to break anything given the very specialized use of this extension - the extension author signed off on it.

and having e.g. ...typedef void VkFoo; is redundant and error-prone

I assume, you're referencing some vk.xml lines like
<type category="basetype">typedef <type>uint32_t</type> <name>VkSampleMask</name>;</type>

For such a line, I would have expected a description like
<type category="basetype" type="uint32_t" name="VkSampleMask">

While the current line is kind of "annotated C code", the latter would be a bit more language independent.
But, well, it is what it is, and it is probably far too demanding to ask for such a fundamental change in vk.xml ;)