I haven't done a detailed review of these patches, but looking over them at a high level, the general approach seems right for all of these, so I think it would make sense to start submitting them (a few at a time).
I do have a few high-level comments that might be good to address sooner than later, though.
From "vkd3d-shader/hlsl: Span variables across multiple register spaces.":
* "The 'reg' field is still used for numeric register spaces. The HLSL_SPACE_DEFAULT value can be used to indicate this." — My inclination is that we don't want to do this. We should just use one array, probably an array of hlsl_reg structures (even though writemask is meaningless for anything non-numeric). Same for reg_size vs reg_space_size.
* HLSL_SPACE_* naming could be improved, I think. It's written to match the bytecode, but I'd advocate for SAMPLER and TEXTURE instead of S and T, and probably NUMERIC instead of DEFAULT. [Although... hmm. While writing this I realized that this does make it a bit easier to mix up HLSL_TYPE_TEXTURE and HLSL_SPACE_TEXTURE. Still...]
* Also, "reg_space" is... a bit unfortunate, since "(register) space" also means something else (specifically, sm 5.1 register space). Unfortunately what we're dealing with is namespaces on namespaces. Some other names that occur to me are "set" (although that one means something else for Vulkan), "namespace", "reg_type". "Set" is probably my favourite, especially since that matches the d3dx9 terminology. I'm open to bikeshedding this one though.
* We probably want to move away from storing reg_size (and hence also reg_space_size) in the variable. I don't mind deferring that one to later, though.
From "vkd3d-shader/hlsl: Skip object components when creating input/output copies.":
* Why this patch? Is this broken now?
From "vkd3d-shader/hlsl: Track object components usage and allocate registers accordingly.":
* This one looks fundamentally sensible. It may be an open question whether we want to merge the first_write/last_read fields into object_usage (and make the whole thing completely per-component rather than just per-object-component) but probably makes more sense just to leave it alone for the moment.
* hlsl_reg_space_range_from_deref() is odd here, because, why the count parameter? As far as I can tell it's not used in this patch.
* request_object_registers_for_allocation is one of those things that we can probably do as part of track_object_components_usage(). I.e. count = max(count, index).
The last few patches related to sorting—can these be put into sm{1,4}_sort_externs() instead of being separate functions?