With the existing algorithm i was getting horribly inconsistent results from run to run. To figure out why, I constructed a spreadsheet simulation of the algorithm's behavior under varying temperature change histories. This made it easy to see that the "calibration" it did depended strongly on how the temperature varied with time during a calibration run. Not good.

The new algorithm is much less sensitive to that effect.

Testing with the new algorithm yields much better consistency, but there's still something not quite right. The calibration data ovr many runs hints that my test clock undergoes some sort of (tiny) discontinuous change over time. The symptom is that after several days there is a sudden change of about 0.1% in the speed at which the clock runs. Once this happens, the clock runs at the new speed until, some days later, the speed shifts once again. My guess is that something in the clock expands and contracts in a stick-slip fashion as the temperature changes.

Looks like I need to think about physical design some more.