I’ve heard this explanation before, and it is really a non-answer:
The tempo of recorded clips is correct when not using Cycle, but broken only when recording in Cycle mode. Surely you’re not saying that somehow one no longer cares about the Grid when recording in Cycle mode? Yet somehow we do when not cycling???
I understand that an algorithm is doing this, and maybe you, personally, don’t see its abject failure as a problem, but clearly the algorithm doesn’t work in this most basic use case: cycle recording multiple takes of a live performance. It doesn’t even provide an answer at all, just “???”. Surely, you’re not saying that this is the expected and designed behavior?
It would be a colossal mistake to try to explain the bug as a feature, saying, “See, the algorithm can’t figure out the tempo, and thus throws up it’s hands, just like it was designed to. Therefore, the algorithm - and Cycle recording - are working just fine.” aka, “It’s not a bug, it’s a feature!” Thanks, engineers.
In this case, the magic doesn’t work. At all. It should at least have a way of being turned off (and arguably not the default).
There are plenty of other, on-demand operations in the Sample Editor for working with beats, Hitpoints, Slices, etc., That would seem a much better place for the automatic Tempo detection that this algorithm does, rather than where it is in the flow now.
In any case, clearly this algorithm, as currently implemented, should not be the default, with no way to disable it, as it breaks this most basic and very common - and very well documented in the Operation Manual - use case.