Good question. I imagine that for instruction encoding density one could for example encode instructions so that "add4 ra0, rb4" would do a 4-wide addition ra0+rb4 up to ra3+rb7.
Possibly with restrictions like only "aligned" register access, ie an 8-way op can only use regs 0-7 or 8-15.
Swizzle instructions can then handle reordering ala SSE.
I was just thinking of the back end ALUs but you make a good point: it might also make sense to unify scalar and vector instructions. If the right encoding is used it might allow scalar code to retain its efficiencies.
For unified scalar and vector instructions, MRISC32 might be interesting: https://mrisc32.bitsnbites.eu/. Though it still has separate vector & scalar register files, and I don't think it's intended for the type of thing discussed above.
For "just" the back-end I was thinking the instruction count overhead would outweigh the gain. That is you'd get less effective instruction cache and require far more decoding units from all the instructions required to fill all those ALUs.
So yea, that's why I was imagining an ISA where you'd have instructions that were 1, 2, 4 etc wide, encoded in the instruction. You'd only need two bits for up to 2^4=16 wide instructions.
Of course could be I am terribly mistaken, I'm by no means an expert in this.
Possibly with restrictions like only "aligned" register access, ie an 8-way op can only use regs 0-7 or 8-15.
Swizzle instructions can then handle reordering ala SSE.
Don't forget about 2-way ops as well.