Yes. Retroratcheting (manual or automatic) does not respect breaks (manual or automatic).
I’m only speculating here, but my guess is that it is these features don’t work correctly together because they are each implemented in the easiest way possible, when considering each in isolation.
Beeminder has no persistent record of a “break”. There is only the road shape data, which is a list of tuples (called “bricks” sometimes). When you use the Take a Break UI, a brick gets inserted into the road. But there’s no metadata recording the fact that this brick corresponds to a break.
When you want to retroratchet, sliding the road to the left usually requires editing fewer bricks than sliding the road up. Although now that I think about it, I’m not sure I actually fully understand the behavior myself. I had typed out an example for you but it was invalid because I was assuming that when presented with a non-monotonic road, the behavior is to set you to the first occurrence of a safety buffer of the requested size. i.e. in this horrible drawing which red circle do you end up sitting at when you retroratchet to 0?
Anyway, I think for normal looking roads you always have to edit fewer bricks to shift left instead of up.
I realize in hindsight that maybe this post isn’t very useful. But I’ve never heard any argument articulated in favor of retroratchet’s current behavior so my assumption is that it is something to do with keeping the code simple.