PPPoE server interfaces are renamed by freeradius from ppp<number> to ppp-<username>:
post-auth {

update reply {
        NAS-Port-Id = "ppp-%{Stripped-User-Name}"
}

...
and their IPv4 /32 routes are redistributed in OSPF with "redistribute connected" and "redistribute kernel" (following some advice by AI that "redistribute connected" alone is not sufficient), likewise their IPv6 routes (both framed /64 and delegated /56) in OSPFv3.

But "show ip route connected" and "show ip route kernel" show diverging sets of stale routes with numeric identifiers like ppp5.
"sudo service frr restart" is an intrusive but working way to resync FRR state with current PPPoE sessions.
The setup described above has been working fine for a long time in 1.3.8 but broke in 1.5 - not sure exactly when in between.
Google AI suggests the newer FRR is event-driven and sometimes misses events when ppp interfaces are renamed (and then hallucinates "fixes" that don't work, like renaming the intefaces directly in accel-ppp which is not yet supported in VyOS).
If the underlying race condition is difficult to fix, it would be nice to have a less intrusive way to rescan the dynamic interfaces and run it periodically - only clean up stale ppp interfaces without touching the correct ones, restarting BGP sessions etc.