To somehow deal with this without completely reconfiguring the running gw/fw (you want a fast exit strategy if things don't work as planned...) I'd go with an additional OpenBSD router in front of the current fw/gateway and put each of the uplink interfaces in its own rdomain. This way you get a clean separation of the uplinks and can use the same default route on both rdomains. You can then add an internal interface (+different address) to each of the routing domains and run a bgpd instance in each rdomain that announces the corresponding internal IP as a default route.
This router also deals with NAT for egress/ingress traffic, so all your internal gateways/firewalls are now using private (rfc1918) IPs on their 'external' side! Use a distinctively different prefix/subnet for that network than your internal/private ones and put that routing network in its own, protected VLAN! You absolutely don't want any weird traffic from servers or god forbid clients and wlan devices on that network!
Your current gw/fw(s) then peer(s) with both bgpd instances on your router and you can either use preferences to prefer one default route over the other or try your luck with load-balancing. However, without proper support from your ISP (-> BGP multi-hop) this *will* cause headaches because egress packets will originate from 2 different IPs. Prepare for broken VoIP and weird behaviour with encrypted connections and sessions.
I'd rather divide traffic by priority, e.g. use the more stable and/or broader link (if there is one) for traffic from/to important networks/hosts/services and the second link for stuff you don't care that much about (clients, guest-wifi etc...). If the network is properly segmented, this is just a matter of redirecting traffic from given subnets via simple rdr rules to different FIBs (if using FreeBSD) or putting the (vlan) interfaces in different routing domains (OpenBSD).
To detect if one uplink is down and removing the route you can try using 'depend on' in the bgpd configuration and/or a script that e.g. ping-checks the gw. This won't give you the fine resolution and transitioning as a proper eBGP peering /w short keepalives, but at least your routing will adapt and fail over automatically.
It *could* be done completely with a single FreeBSD host and different FIBs, but I find OpenBSDs rdomains far superior and easier to deal with as you get a proper separation. Running services (bgpd) in context of a specific rdomain is also a huge advantage. The FIB handling on FreeBSD via PF can (and usually will) get quite messy and I've always encountered weird edge-cases esp. when transitioning where it breaks in subtle ways that aren't very fun to debug.
I've also done failover via scripts that hooked into PF and/or modified the routing table, but mangling PF or routing tables via script with possibly flapping uplinks is rather fragile and a pain to debug and was never as reliable and scaleable/adaptable as any solution using dynamic routing (BGP and/or OSPF) I've build since.