The simplest method would be to just track that information within each "mineral inclusion" record, of which there is typically one per vein/cluster per 16x16x1 map region - they already keep track of the inclusion type (so that small clusters can give a 100% drop rate), so adding a pair of "successful mines"+"failed mines" variables would be easy and wouldn't increase memory usage in any significant way.
I was thinking of something between the fully railroaded reversion-to-the-mean[1] and total memorylessness[2]. Ideally, it would have infinite
full sequence memory, from which the compound sum of various length rolling-averages would influence the next pick. Not so much based upon either the full sequence or the immediate predecessors as a short-term FIFO stack, but blips would spark de-blips at various points, especially if the blip had not prevented a further re-blip recently (always should be possible) and thus now more de-blips are needed.
And to be implemented as everything(plus)subtype(plus)exacttype so you get exciting blips(/deblips) just to offset more-/less-global deblips(/blips) for an dditional piquant of de-dampened chaos.
This, far moreso than the simple count you give,
would require much memory. At a pinch it could be rationalised to jot be a fully-literal sequence[4], but still would accumulate.
Also, I should say, this was not exactly serious as a suggestion. It was an overcomplicated solution in the fine tradition of overcomplicated dorfy things in general.
(I could have suggested a pre-prepared dithered procedurally-ratioed btmask of yay/nay results (or maybe skill thresholds needed), that only individually surprises but is strictly in range when you consider the whole. The randomness is introduced by player choice of where and how to dig them out. Does lend itself to DFHack interrogation (for 'cheaty' reasons) or save-scumming for the best approach (unless saves/reloads recalculate the unrealised determinations to a new pattern). Of course, I'm
still leaving a component of annoyance, because I think it needs it for verisimilitude, but trying to knock the corners off the main annoyance of the current chances of getting a whole-lotta-nothing from much effort.)
[1] Is totA/totNotA>ratio? Then NotA. Is totA/totNotA<ratio? Then A. Else flipacoin?[3]
[2] An infinite sequence of any single result is (albeit infinitesimally) possible.
[3] If not, but >= or <= are used it's a strict repeating sequence. Done differently it could be some higher-order version of the Thue-Morse sequence, maybe.
[4] Sequence= [last], then [last,prior=previous.last], then [last,/,lastpair=previous.last+previous.prior], repeat to insert newer lastpair with priorpair=previous.lastpair, then the next shuffle involving the pairs bumps them into a combined lastquartet. (Names here just for 'readability'. It'd be just stacks that
only lengthen as order LogN to the total individual values individually stored to it. And in a format (sum of each like-'sized' total) compatible with my intended sum-of-running-totals 'scheme'.