Of course, it's an open ISA, so you can do whatever you want. The style of virtual memory you choose to use will depend on the target application.
From a security and reliability perspective, I'm saddened to see that rwx got supported while --x did not get supported. That is backwards. Having to change permissions after code modification is not bad; this provides a convenient point for cache flushing and ASLR-enforced address changes. Preventing executable code from being misused as data is valuable.
I'm also saddened to see that user access implies supervisor access. This too is exactly backwards; nothing should be both user and supervisor accessible. Given that data access can be performed at a less-privileged level by setting MPRV=1, the ability of the supervisor to access user pages normally is especially strange.
Lack of distinct did-execute and did-read bits is mildly annoying. If a page is marked as being accessed and executable, one must assume that it is now in BOTH the instruction cache and the data cache.
I have mixed feelings about having page frame numbers shifted over by two bits. The win is Sv32 getting a reach of 16 GiB. I suppose this is worth the minor annoyance when debugging OS kernel code.
Other than that, I like it. It's certainly sane. The traditional page table is pretty good for the middle bits of the virtual address. I think it is less good for the upper bits due to ASLR, and I hate to see anything that encourages a failure to use all 64 bits of the virtual address space.