We are having some success with the static variation. I simply added a new flag in the STATIC DHCP OPTIONS to tell pfSense to use the V4 link, which is of course PPPoE; then added that option into interfaces.inc and that solved the dpinger issue.
Are you using the existing DHCP "Use IPv4 connectivity as parent interface" option in the UI to trigger this flag (i.e. $config['interfaces'][$interface]['dhcp6usev4iface']), or is another flag needed?
That leaves me with a 'to do' on the gateway possibly changing and I can correct that by enabling accept_rtadv on the PPPoE interface and making rtsold launch the IPv6 WAN update.
Is that not covered by the work I did in pfSense Redmine #5297
and the subsequent tidying up in #5621
? The code, as it was after that work, was still messy, hence the suggestions for tidying up and refactoring in #5993-15
. I've been out of the loop for a bit, so don't know what subsequent changes have happened in this area.
My apologies if I've overlooked something in your design in these comments. The area is ripe for possible races and varying behaviour of different ISPs.
As for dhcp6c, it appears to be as solid as a rock now in 2.4 after we did a lot of work adding locks and modifying the client itself, I don't recall seeing any issues on the pfSense forum for some time now.
I was really pleased to see that work being done. dhcp6c was sub-optimal in various ways and it being brought back from pretty much abandonware status after the disbandment of the KAME project to become maintained and (somewhat) actively developed again was very welcome. The lack of locking was particularly frustrating.
Dual ( or more ) WAN dhcp6c is a bit of a headache, as it's a case of which comes first, chicken or egg. For example, Sky require dhcp6 solicit before RA, other ISP's want it the other way, my brain gets tired just thinking about that, I think if you have an ISP such as Sky then you are not going to be able to have two dhcp6 WAN's unless they are both Sky!
I remember how my brain got fried when working on #5621, which was eventually committed on the basis that it was better than what was there and nobody, including Chris Buechler who reviewed it, could find anything incorrect in my reasoning.
It's probably better if you can post me to the pfSense forum thread(s) covering your work in progress, and/or a Github repository. If you weren't aware, you can do very powerful things with Github's diff functionality when combined with the pfSense system patches package. In particular, you can download, test and install a patch between a branch of the pfSense repository and a feature branch in a fork of that repository - see the 2.3 recipe in this old pfSense forum post of mine
(N.B. this was in the pre 2.3-RELEASE timeframe, so the master branch was 2.3 at the time).