If this is the case then I think everything I wrote in the post a What are the technical reasons for the incompatibility between autoratcheting and weekends off? - #7 by drtall stands? i.e. the bogus derail does have an effect on the overall rate of the road if there’s always a buffer inserted.
I think this philosophy is the root cause of a lot of needless technical debt in the software industry. Especially in medium sized companies where they (rightly) took that philosophy when designing their initial product but then keep using the philosophy to bolt immature things on to a now mature ecosystem. I agree that it’s a common practice but I don’t know if it produces good results down the road.
My understanding of shirk-n-turk is that it’s about choosing a different implementation (code vs humans), not lowering the bar on correctness. I thought the philosophy was all about not compromising correctness in a rush to automate. Here we have the opposite, where it is automated but it’s done incorrectly.
I usually assume that the Beeminder employee base has heard quite enough from me. 
Regarding this specific bug, I emailed about this in Nov 2017 and I’ve been involved in various discussions: Why does retroratcheting change scheduled breaks? - #5 by drtall , Precommitting to data points - #2 by insti , Triangular beeminding for tracking alcohol consumption - #38 by drtall , Detecting auto-retroratchet in the API? - #4 by drtall . I’ve probably talked about it elsewhere that I’m failing to pull up in a search too.
Frankly this class of bug is one of the original old chestnut bugs of Beeminder which has worn me down to the point that I don’t talk about it much unless prompted.
No, I 100% believe you would honor it. I just think I would feel weird about it, as I’ve tried to explain above.
I’m game to try but if the very first quote is right then it won’t really help I think? I mean if there’s not going to ultimately be a guarantee that the road has a certain average rate.