As i understand this it seems to be because when the first pppd is
   terminated it deletes the arp entry and route to it, there is often
   some packets still going to the the said ip as the pppd machine
   sees it sees that the ip is on the same network as it it tries to
   send it to ethernet and generates bogus route and missing arp entry
   for the ip, now the seconed pppd fails to create arp entry or route
   for the ip.

   [...]

   I think that the way to fix this would be to change pppd to remove
   routes and arp info before trying to write over them, of course it
   would have to check that the route is not a valid one.

That would work only if a packet isn't sent (causing the route to be
regenerated) between the time the bogus route is deleted and the time
the correct route is added again.  What's really needed is a way to
force the new route to take precedence over a cloned route atomically.