I don't care much for this particular patch; mostly because it's an approach to this issue that I had previously considered and rejected.
The obvious disadvantage here is that vkd3d-compiler will basically print every fixme message twice.
Yes, unless vkd3d-compiler sets its own debug callbacks or fiddles with VKD3D_SHADER_DEBUG at least.
Fundamentally, I think vkd3d-shader compiler output should go through vkd3d_shader_message_context instead of TRACE/WARN/FIXME/ERR. That's not to say it doesn't make sense for d3dcompiler and/or vkd3d to be more verbose, but I don't think we should be making that decision on the vkd3d-shader level. It's perhaps also worth pointing out that there are parallels to handling GLSL compiler output in wined3d.
The question would then be whether the existing API is sufficient for d3dcompiler, vkd3d, and wined3d. If it's not, we could certainly introduce additional API to fix that. For example, we could introduce callbacks that receive compiler output with the location, log level, error code, and message already separated out. It's not necessarily clear to me that some variant of what wined3d does in shader_spirv_compile_shader() wouldn't be sufficient for d3dcompiler/vkd3d though.