Thank you to everyone who has responded!

Going through the responses, and thinking a bit more about the
particular details of what I'm attempting to solve for, I could
have been much more concise, apologies.

I think I'm going to live with my edge case and handle it
another way. It's too small to be concerned with at this time.

My use case was N nodes, advertising the same space into the DFZ;
For certain (very limited) connections, I was thinking it would be best
to be able to "defer" across more than 1 other node.

From a functional perspective, I think a way to have the "defer" flag
functionality apply to N nodes, and the ability to control N in
runtime, would address my small edge case.

The edge case is thus: suppose 3 nodes advertising the same IP space,
"A", "B", and "C", all running pfsync. Suppose a client "Z" connects to A,
and just as they open a connection, routes change such that traffic
from "Z" ends up going to "B". If "A", "B", and "C" are all using pfsync
with "defer" set, I was worried that it could be possible that "B" didn't
receive the pfsync message by the time "Z" sends a subsequent packet.

After some reflection, it's almost a contrived example edge case, given
how low likelihood it is that routes from "Z" to the system would change
at that instant, and also that the latency would have to be such that a
pfsync message from "A" to "B" took longer when compared to
( "A" to "Z" + "Z to "B" ).

In any event, thank you all for the responses and thoughts.