...and only on D3D11 (although Metal has not been tested but based on the docs it should behave similarly to OpenGL and Vulkan)

This would show up with, for example, a CustomMaterial that has its source/destination factors set to one of the Color contants, say OneMinusSrcColor. The value then ends up in both srcColor/srcAlpha (or dstColor/dstAlpha). So far so good.

However, D3D11 explicitly disallows using _COLOR (e.g. D3D11_BLEND_SRC_COLOR) in SrcBlendAlpha and DstBlendAlpha in D3D11_RENDER_TARGET_BLEND_DESC. Which is only bad because everything else accepts the equivalents, presumably mapping internally based on being a color or alpha factor (e.g. see the table in https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkBlendFactor.html )

So it's up to the D3D11 backend of QRhi to do some mapping as appropriate. (so that SrcColor maps to D3D11_BLEND_SRC_COLOR for SrcBlend/DstBlend but to D3D11_BLEND_SRC_ALPHA for SrcBlendAlpha/DstBlendAlpha etc.)