Existing pppd would have to be using one of simple, forking, oneshot or idle to indicate that it is up. And quite possible they have deemed that too unreliable for whatever use case they have.
The other options would be to modify the existing pppd to use dbus or notify. And at that point they may well have gone with reimplementing the parts of ppp they need for their existing use case.
Teaching it to notify via dbus is as trivial as passing a bunch of `connect /usr/lib/networkd/ppp/ip-down`-type options or writing a simple plugin library to do dbus messaging or `sd_notify` calls. Available plugin API hooks should allow for anything necessary to have a good understanding of pppd's state and provide a good amount of control over it (link state changes, authentication, IP address negotiation, idling etc) when necessary: http://ftp.samba.org/pub/unpacked/ppp/PLUGINS
I'm almost certain there's no need to write a whole new pppd from scratch.
They can write a full-fledged pppd replacement, but can't just have pppd as a child process and happily control it? (May possibly need a tiny patch or two, but that's barely an issue)
I'd get it if one needs some very tight integration, but pppd is self-sufficient, fairly controllable and well-tested.
Looks like NIH syndrome to me. But maybe I'm missing something from the picture and pppd isn't a good fit. Then, okay.