Just an update on this... I _had_ two systems with this problem, but have found a possible workaround?

Hypervisor is VMware ESXi. I believe these were installed from OVA several
months ago, but haven't reproduced recently.

Yes, this _was_ still a problem but the workaround solves the issue for
me. I've been able to upgrade the 1.1.8 instances to 1.2.3 after adding
this extra interface route.

Unfortunately I still see the problem when the blackhole routes are set with a distance of 240 and the 0.0.0.0 route is distance 1.

The problem discussed here sounds remarkably similar to what I'm seeing: https://github.com/FRRouting/frr/issues/2230

I've tried several variations on the VRRP configuration, and it doesn't seem to make any difference. As far as I can tell, nothing is wrong with VRRP. It is only relevant as a source for change in the routing table. I can demonstrate the problem on a single instance with no VRRP.

The abnormal part of our setup might be that we have blackhole routes in
place to prevent any accidental leakage of private IP addresses through a
public class C network. The configurations posted above are contrived -
purely to demonstrate the problem, but it does reliably demonstrate the
regression from 1.1.8 to 1.2.0.

From the 1.2.0 instance (10.240.4.31) I'm able to ping the 1.1.8 (10.240.4.32) instance immediately after adding the address, but cannot ping out to the internet until after a reboot.

This won't help in production case, as that uses a /30 network with only 2 possible addresses. One is the floating VRRP address and the other is the destination for the static route.

One fairly simple workaround is to add a couple lines to /config/scripts/vyatta-postconfig-bootup.script

Unfortunately this is still not enabled in 1.2.0-rc8.