It depends on what you have in mind exactly, I guess. There's certainly an argument for introducing "split" variants of these instructions with two outputs like IMUL and UDIV, but also e.g. SINCOS, particularly since we're effectively splitting them for SPIR-V (and GLSL) output anyway. I don't think that needs to be an issue for the disassembler though; we can just keep the complex instructions in the IR, and lower them to the simpler variants before producing output, much like we intend to do for some of the more complex texturing instructions from shader model 1-3.
I guess that's a potential way forward. I'm not completely sold on it, because even having different opcodes that do the same thing is an element of complexity, not necessarily welcome in an IR; it can be mitigated with other passes, true, but that's also an element of complexity, and more code that has to be maintained.
Speaking of which (but that's not related to the assembler or the semantics), another aspect that makes the way we currently use VSIR not ideal as an IR over which to run passes is that it is stored as a big array, so adding instructions in the stream means moving a lot of data. For HLSL it's easier, because instructions are linked. I guess if we want to start doing passes on VSIR seriously we're converting that to a linked list too?