I don't see any harm in allowing an empty bitfield, but I think a plain bitvector would be fine for most use cases - you would just use mstateen1 directly without needing mstateen1.bits.

There are some interesting issues to do with empty bitranges: in a normal Turing-complete software setting, an empty bitvector is type-isomorphic to the unit type. This is because we can still communicate termination/non-termination with unit. So even a value of unit type communicates information.

But what happens with RTL, e.g. Verilog? Should we still generate a port for empty bitvectors? There are reasonable arguments either way ...

In this case it's about having a bitfield with no fields, but the underlying bits type would still be non-empty like bits(xlen).

I don't think it's correct to say that unit tells you anything about termination, as both:

function f1() = ()
// and
function f2() = while true do ()

have type unit. The current SystemVerilog generation will try to remove unit ports where possible, as there really isn't a good way to represent a zero-width type in SystemVerilog.

For Sail zero-width bitvectors, i.e. bits(0) the SystemVerilog translation will translate them into a variable-width representation as a length * value pair. Not sure if they are common enough to warrant a more sophisticated encoding.