What matters is the spec though, and I think it disagrees with the validation layers here; VK_KHR_external_fence_capabilities, VK_KHR_external_memory_capabilities, and VK_KHR_external_semaphore_capabilities all add VkPhysicalDeviceIDProperties/VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES.
In the case of wined3d, VK_KHR_external_memory_capabilities was added specifically for VkPhysicalDeviceIDProperties in commit 035dc483881225fb8181f5e4ad85d05ba5c3b989.
I see. This made me realize though that wined3d is currently wrong since the array contains VK_KHR_external_memory (device extension) instead of VK_KHR_external_memory_capabilities (instance extension). Regardless of this, it seems that there is indeed a bug in the validation layer, perhaps they got the same confusion (?). I replaced VK_KHR_external_memory with VK_KHR_external_fence_capabilities then.
I suspect the win32u usage of the same extension similarly originates from commit dd25789fb24e257baea4b257deddad44d5b6fedd, but I didn't verify that.
I traced it back to 4a98b07c4bcc35a698448261478ba856c149cbea as it went through several moves. VkPhysicalDeviceIDProperties is also used there so that might be the rationale behind its inclusion. I replaced it with VK_KHR_external_fence_capabilities and the validation problem goes away, but I can't say I am sure that VK_KHR_external_memory_capabilities isn't used somewhere else by win32u since then, it might be safer to keep both extensions. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11002#note_141768