I can’t answer your questions, but I can distract you with shiny alternatives. 
For MOST development, the emulations provided by QEMU and Renode.io are sufficient. They’re fast. You can single step through every opcode, including boot and in the exception handlers (where you couldn’t debug without JTAG) and they’re easy to automate. Entire editions, including graphics, of Fedora and Debian and FreeBSD have been running in emulation for a long time.
GitHub - riscv/meta-riscv: OpenEmbedded/Yocto layer for RISC-V Architecture contains information on automating CI with a QEMU instance that emulates this specific hardware.
I’ve been using Renode.io for my own development. Emulation is just easier than fighting tftpboot or sd cards and JTAG pods and such for those early days of “the OS quit and I don’t know where it went” and “I can see the timer ticking, but I’m not getting any interrupts. Why?” saga.
See also:
for my personal success story bringing up an operating system with Renode. There will be parts that I will have to build on “real” hardware, but automating CI to build, boot, start a few threads to compute some prime numbers, etc. will be hugely handy.
Not all hardware is virtualized in high fidelity. When it comes time to do GPIO, for example, I’ll probably ping-pong between real hardware and then implementing the GPIO hardware in Renode. If you’re building apps instead of OSes, that probably doesn’t matter.
I’m “just” a volunteer developer and don’t control board distribution nor do I know how many are left. I don’t get the impression it’s a lot. I do know that Beagle has coordinated a hell of a team to get all the pieces of the various OSes and tools running on these boards so that when final boards DO hit, they should be quite usable - and awesome.
It’s exciting times for RISC-V - and my four month old article is already needing a follow-up.