My understanding from the "Remarks" section in https://learn.microsoft.com/en-us/windows/win32/api/d3d12/nf-d3d12-id3d12com... is this: suppose you create a command list that paints a resource all red and another one that paints the same texture all green. If you submit the two command lists with two separate `ExecuteCommandLists()` invokations, then you're sure the resource will be painted in whatever color is submitted last;
Well, sure, but command buffers submitted to a Vulkan queue don't quite execute in random order either; submission order, primitive order, rasterisation order, etc. are all defined by the spec.
Conor's comment seems to suggest this may be about ordering compute and graphics commands, which indeed normally don't wait for each other in Vulkan. Handling that wouldn't quite require a full memory barrier after each submission though. (Incidentally, we have barriers in adapter_vk_dispatch_compute() and wined3d_context_vk_end_current_render_pass() in wined3d for essentially this reason; there may be some room for optimisation there as well.)
In any case, it would be nice if we were at least able to reproduce the issue this is trying to fix...