What makes the aforementioned workarounds ugly or difficult?
A simple example is a typical buffer use in form of calls: (1) `vkCreateBuffer()`, (2) `vkGetBufferMemoryRequirements()`, (3) `vkAllocateMemory()`. Delaying is not enough because we need a handle for (2). If we re-create buffer in (3) we have no guarantees that the result of (2) is still valid (it's probably valid in practice, but implementation is free to return different requirements for host importable buffers).
Also, wrapping buffers/images means a lot more unwrapping code even for targets that don't need it. The number of required private thunks also quickly grows, meaning non-trivial future maintenance cost. This could be bearable if we didn't have a choice, but with VK_EXT_map_memory_placed on the horizon, I think it's valuable to keep fallback code path simple.
If this isn't going to expose optimal performance anyway (I at least think two games are not really enough to accurately measure a difference), I would assert that we should do something slow yet completely safe, like copy the whole buffer, as with GL.
I wouldn't call memcpy() solution safe. At very least because it would require quite invasive changes and memory coherency would be just broken. I would expect something like that to quickly get very ugly.
Failing that, I'd just say it's not worth merging this. But then again, I suppose I also don't understand the rush to merge WoW64 upstream at any cost of performance or correctness, without first addressing those costs.
I'm not sure what you're referring to. The MR was marked as a draft for a reason. And even if we had VK_EXT_map_memory_placed available tomorrow, having some fallback for existing drivers would still be interesting.