Redundant L2L VPN peers with the same encryption domain?

I've been tasked with devising a redundant L2L VPN solution for our enterprise. We currently use an active/standby failover pair of Firepower 4125s to support around 70 VPN connections. The ask from management is to implement a new firewall/pair at our secondary data center, which would be used as a fallback for L2L connections in case we run into a power or circuit issue in the primary DC.

My first idea for this was to have the spoke VPN firewalls configure multiple peer IPs (one for each of our VPN firewalls), and if possible, to utilize the same /24 address space for the encryption domain for both peer connections.

Theoretically, it seems like this would be a good idea to ensure that our servers are always reachable by the same IP over VPN, and therefore no manual changes would be necessary. Advertisements for the /24 would be handled by BGP in such a way that the secondary DC is not the preferred inbound path until the primary goes down (i.e. path prepending).

I labbed this out in GNS3 and was able to see reliable connection recoveries after a fault at the primary DC's internet router. BGP would converge after a couple of minutes and a new VPN connection would come up at the secondary DC. But, if I simulate a power outage by simply turning off the primary DC's firewall, the connection never fails over to the secondary DC until I remove the old peer from the remote VPN firewall. I'm using IKEv2 for the lab on ASA 9.14, so redundant peers on the remote side are ostensibly supported. It could be a routing issue in my lab, but if it is, I cannot find it as everything appears to be routing correctly.

I'm at a point now where I'm not particularly confident in this design. It feels like there is a better way to solve this problem... Anyone have experience trying to create L2L redundancy across two different sites?

I'm leaning toward using different /24 address spaces for each VPN firewall, but this isn't 100% ideal because many of our third-parties with whom we have VPN connections would be forced to make manual changes to point at the new server IP in the event of a failure at the primary site.