The vector extension yes, the C (compressed) extension is unusual: you can have 32 bits instructions aligned on 16bit, while nice for code density this means that the implementation is much more complex than Thumb/MIPS16 extensions..
RISC-V has a variable-length instruction encoding. It's just that unlike x86 you can easily tell from parsing a few bits the length of every instruction in the stream, and like MIPS etc most "ordinary" instructions are 32 bit.
BTW if unaligned 32 bit instructions are a concern there is a Compressed NOP (C.NOP == addi x0, x0, 0 but without RAW hazards).
C.Nop isn't a solution, if you implement a compliant RISC V processor with the C extension you need to handle all the possible case, for example an instruction straddling several pages.
Thumb2 -- which is the only ISA available on 32 bit Cortex M devices and the main ISA for a decade now on 32 bit Cortex A devices -- mixes 16 bit and 32 bit opcodes arbitrarily, with 32 bit opcodes frequently on 16 bit boundaries.
It's simply Not That Hard to deal with. You just need to have two 32 bit words in your instruction decode buffer. Sometimes you need the 1st half of the 2nd word and sometimes you don't.
Incidentally, once you've done that, arbitrarily aligned (on halfwords) 48 bit instructions don't need anything extra.
The RISC-V Vector ISA is credited to Cray "vector processors" [1], explicitly by the RISC-V authors.
Additionally, I believe experimenting with vector ISAs was mentioned as one of the reasons they started another RISC research project, which ended up being RISC-V.