If there was a way to deposit values in memory (even if just hex into RAM), you could use this monitor to load small programs onto your RISC-V device. (this was occasionally used to load code on the original IBMPC using the "debug" utility. You could load hex into RAM and save a .com file.)

I suggest accepting Intel Hex format lines, which would make the "command" be ":", provides some error checking, and is compatible with the output of many compiler tools.
There's some simple C code that does this here: https://github.com/WestfW/Duino-hacks/blob/master/hvTiny28prog/simpleParser.cpp#L271 (I don't think I'm currently up to converting this to RISC-V asm.)

(Extra credit if you can make an assembler, using the same instruction names already present in the disassembler.)

divrem in math.S includes an instruction:
slli bit, bit, 63
which doesn't seem to be accepted on 32bit CPUs.

When disassembling, show this

.d 800009f8
,0x800009f8:00008067    ret	
,0x800009fc:0001        c.nop	

instead of this

.d 800009f8
,0x800009f8:00008067    ret	
,0x800009fc:00730001    c.nop	

F aa bb cc ..., xxxx yyyy
Find all occurrences of the byte sequence aa bb cc ... in the memory range xxxx to yyyy.

The various strings used in vmon are what C would call "read only data", which the linker would eventually merge into the .text segment. There might be some "locality of reference" advantages to putting the strings in .text or .rodata (I guess because of the inline nature of the cmd_xx files, using a separate segment has advantages over just using .text)

On "real hardware", .text and .rodata would go into flash/rom, a significant advantage over .data (in RAM) that would need to be copied at startup and/or manged WRT sharing RAM space with the application.

The "i" command should output some information about what extensions (and what XLEN) are supported in the actual executable.

copy memory area from A to B (which could especially also be useful to copy data from SD cards or such)

"W xxxx yyyy zzzz - Write
Copy the memory contents between xxxx and yyyy to zzzz. No address or other transformations are performed. Works correctly even if source and destination range overlap."

Feature-wise nothing to be done. Compiling for RVE will require refactoring so that only registers x0-15 are used.

Refactor Makefile so that it is not necessary to comment/uncomment different targets for the build process.

Figure out if everything can be done without

#if XLEN >=64