Pretty sure that the way it appears to work is that it has an integer counter tracking failed attempts, and just multiplies the chance modifier of the dice against this number to produce the current probability. Which means if you have 20 fails, switching from PD12/10 to PD6/8 will drop your success rate, and increase it going the other direction, without having made any attempts.
They need to also track the probability as a float and peg the current probability to that number rather than reconstruct it (badly).
So rather than a forumula like dice * failed count * probability modifier you get previous probability + dice modifier at current fail count.
This is such a basic, common programming pattern I'm surprised they didn't start with this.
@rare rain Then they need to not have two separate tracks of probability. Because the solution above to maximize your gains using a mix of PD8/10 and PD6/12 is also complicated and opaque.
And why should you benefit from past failed attempts using PD10s/12s? Because imagine burning 30 PD12s and then having to continue with PD6s and your success rate is back down significantly below where it was 10 seconds ago. If that's intended behavior, then they need to re-evaluate.
Storing the probability you were at and accounting for the types of dice used is fine, and should be how it is handled. Your average success rate does go up if you use a dice that has a higher probability than one that doesn't. The overall average being higher because you chose to employ those dice for some of your attempts should be the case. That's what happens when you take the average of two different probabilities.
As it is you get no value for having used PD10/12s if you don't succeed with them, because the only thing that is stored is the attempt as integer.