frr-reload's second pass re-sends every line its first pass added (lines_to_add.extend(lines_to_add_first_pass), added in 2017 (frr: 2ce26af100) so that a second one-per-context command like bgp router-id cannot cancel the first). Commands whose handlers do work are therefore applied twice per change:

• neighbor ... maximum-prefix N: the second send clears the overflow hold-down of the sessions that just exceeded the limit and restarts them; they relearn and exceed it again;
• bgp default local-preference, neighbor prefix-list / filter-list / distribute-list binds, bgp bestpath ...: the re-processing they trigger runs twice.

Measured at about 2.8M paths: changing default local-pref 100 -> 200 ran 12 inbound passes over the route servers (6 with the fix), the commit 307-327 s (266 s with the fix); lowering maximum-prefix on the 80-member IXP peer group dropped each session twice (160 drops; 80 with the fix). In a two-router FRR topotest the stock reload fails 5 of 8 checks.

Potential fix. The second pass sends only its own difference; a third pass re-sends only first-pass lines that the second pass removed (the router-id case), and runs only when needed. Cost: one extra read of the running configuration on commits with a real change (0.44 s at 10k lines, 1.84 s at 40k).