Why dedicate "reserved" opcode space for bit ops that are readily expressed in RVI instructions

[David-Horner]

The latest bit manipulation draft includes section 2.14 that identifies high frequency micro op fusible sequences.
These do not provide a code compression benefit, but could provide an opportunity for improving performance.

It appears to me that many of the bit ops that can readily be encoded into 32bit space are also possible to be represented in RVI instruction sequences; and that an implementation may prefer to fuse these for performance improvement rather than use potentially clawed back RISCV managed opcode space.

Indeed, an implementation may prefer to map these RVI instruction sequences [or the corresponding bit op instructions] into their own custom space as the corresponding bit op to optimize the decode overhead for their chip.

Indeed, indeed, we may NOT want to allocate RISCV reserved opcode space for these "fusible" instructions but in a manner reminiscent of RVC, require the Link Time mapping of these sequences into the vendors Custom opcode space.

We can readily expand the candidates to equivalent instruction sequences of less than 3 RVI instructions, with the vendor making the tradeoff decisions. [In my opinion as it should be].