The update from pfSense+ 23.09.1 to 24.3 immediately broke my network. Note that the update completed successfully.
Upon investigation I saw that kernel routes have gone missing in the FRR 9.1 included with 24.3, but were present in the FRR 9.0.2 included in pfSense+ 23.09.01.
Kernel gone in pfSense+ 24.03 (vs pfSense+ 23.09.1)- sanitised.png
These kernel routes are visible to the system in both old and new versions of pfSense, when viewed with "netstat" (netstat -rn4). Note that for this output, the v23.09.1 and v24.03 outputs are identical, so no need to include a diff.
netstat -rn4 sanitised.png
The reason why my network broke was that there was another route in the FRR "show ip route" - an OSPF-learned default route - which is not shown here as I have since removed it. It was a default route on another router in another part of the network, which had a high OSPF cost, and is used as an alternative path in case the whole firewall dies. It is a low-bandwidth link and should only be used in an emergency. When I upgraded the firewall to pfSense+ 24.3 from 23.09.1, it would then direct all traffic to this other low-bandwidth gateway, instead of sending it straight out its own WAN IP to the ISP.
I have now taken this alternative path's OPSF-learned default route out of the network, so that the firewall can function again.
I suspect that these kernel routes disappearing from FRR is why pfSense preferred some distant OSPF default route over its directly connected default route. I am now relying on the functionality that if FRR doesn't have a route in its routing table, then it defers to the system's routing table, and you can see with the "netstat -rn4" that it does have all the kernel routes.
But relying on this functionality is not robust. It should be fine to have a backup default route in OSPF costed out as to not break anything, but be there to take over in case of an emergency. I shouldn't have to remove that. with the age-old concept of "administrative distance", the firewall should always prefer a directly connected default route, other a high-cost OSPF route.
We really do need these kernel routes back in FRR, so that the FRR can have a proper and complete view of system routing logic. Therefore, I consider this a bug, and not a feature.