VM host does, can expose emulated randomness source.

but it doesn't, so it isn't a solution

No, that's wrong. There are actually a number of ways VM hosts can and do expose host entropy to guests. On x86, for example, they can allow the guest to use RDRAND/RDSEED. On anything with PCI devices, there's VirtIORNG: https://wiki.qemu.org/Features/VirtIORNG . VM hypervisors absolutely implement this service, or similar guest services, and hosting providers enable them.

Sure. But the issue here is when these features are not used correcly. For non-vms, linux uses cpu jitter as a fallback if the random device is missing or misconfigured. But for vms, that fallback doesn't work as well.

I'm sure the kernel devs can make it happen, I don't see why VM devs wouldn't want to add this if thry saw clear demand.

They probably couldn't just use RDRAND and the like since Linux doesn't seem to trust that though, so the API could be tricky.

Being able to have a solution isn't enough, even having a solution in hand people could switch to isn't enough. You need to actually show no currently working setups are going to break as a result of the change, regardless what those setups could do to avoid breaking after the change.

How exactly can existing code break if you change randomness? It's already random! Changing random from random to random shouldn't make a difference.

There's an example described in the article, unless I'm misunderstanding this thread. It doesn't change the output distribution, but rather the behavior around the interface, causing certain users of the old interface to block forever on the new.

"break" in this case means made less random/more prone to malicious attacks, hence made less secure. The code won't break in the sense of visibly failing; it'd just silently switch to being less correct and more vulnerable - which is arguably worse.