Sorry for the delay—I sensed I might be getting tunnel vision, and wanted to come back to it with a possibly clearer head.
There is a conflict between "scanning is an operation that should not depend on any external data"—which I still think is a fundamentally sensible position—and "scanning should make a best guess as to how the bindings will actually be used"—which also makes sense, or I wouldn't have proposed it in the first place.
Or, perhaps more saliently, "scanning should be consistent with compiling".
I still can't shake the feeling that it feels like scope creep, but I also kind of understand where the idea is coming from.
So here's my proposal:
* Allow passing VKD3D_SHADER_TARGET_NONE to vkd3d_shader_scan(). This satisfies the API consumer in me that is perpetually baffled by the fact that vkd3d_shader_scan() accepts a target type. If we receive NONE, we return whatever is fundamentally truest about the source type. In this case I think that means BLENDINDICES is FLOAT. This may end up also being the case if the target type is something nonsensical like SPIRV_TEXT or D3D_ASM...
* We go ahead and automatically map BLENDINDICES to UINT if and only if compiling to SPIRV (or GLSL) and the environment is GL. [Or... should we do it for Vulkan too? The scaled-float formats exist, but are they as well-supported? Plus that'll require a pointless, albeit probably not destructive, round trip in the Vulkan driver.]
* If no environment is specified (environment is NONE or spirv_target_info is missing), we assume Vulkan. This is basically called out in the documentation anyway, but I figured I'd mention it for completeness sake.
* Document that when the target type isn't NONE, we'll return a format that reflects how that target type will interpret the data. I think if we do this we don't actually have to say what that target type will be and under which conditions (or keep it constant across library versions?), although I certainly won't argue against doing that anyway.