As a follow-up, everything I've tried so far appears to work as documented, so that's a rather good thing. The documentation is not the greatest, but certainly rather good, even compared to major western vendors (and compared to most other chinese vendors I've run into). The English is even rather good overall. So kudos to WCH for that.
I haven't tested the USB controllers yet. I intend to test with TinyUSB (which supports the CH32V307), which I'm used to, and see how it goes.
The lack of QSPI is a bit of a bummer, but the FSMC looks quite flexible, and I'm wondering whether it's not possible to implement QSPI using it, as it supports not just asynchronous, but also synchronous transfers.
The data widths it supports are 8- and 16-bit only as far as I can tell, but it may be possible to maybe use it with just 4 data bits? Something to investigate. That would probably require some post-processing to reconstruct data words though, so may not be worth it.
There is a digital video port (DVP), that should be usable for other purposes.
Regarding the FPU, my (for now) limited testing seems to show that performance is not fantastic. I haven't done proper benchmarking, but I'd say, roughly, that typical add and multiply operations take around 10 cycles each at least. It's still several times faster than software emulation, but it's not eons faster.
To add to the list of oddities, the RTC peripheral only contains a 32-bit counter with programmable prescaler (and an alarm register and programmable events), but no date/time registers, so to implement date and time using it, you have to implement it all yourself using just a 32-bit counter. They provide example code for that though in their SDK (in the EVT/EXAM/RTC subdirectory).
As I said earlier, it doesn't look like they documented the 2-wire debug protocol for this chip - there is some reverse-engineering out there, incomplete. As far as I can tell, the only thing they published was the 1-wire protocol that is implemented in their lower-end RISC-V MCUs (CH32V003...), which is not the same thing. The WCH-Link adapter does support both.
Speaking of that, I'm wondering whether it is allowed to use SWD on anything else than an ARM core, legally speaking. I've found this very question on a couple other forums with no definitive answers to that. It would seem that a cautious answer would be "no". Which explains why non-ARM cores have to implement something else, even if SWD would be usable (and would leverage existing tools).