In the simplest terms, Mehta-TDR is to Mehta as ZB is to CFOP. Mehta-TDR solves the cube after EO-Ledge in 2 steps instead of 3, but at the cost of bumping up the algorithm count to almost 900. Compared to ZB, TDR is more efficient, has better recognition, and better algorithms and ergonomics. But since ZB itself hasn't made anywhere close to the top spots in cubing, this comparison doesn't achieve much.
Getting a few abbreviations and definitions out of the way:
All of the TDR algorithms can be found here.
As of February 2021, the TDR algorithms have undergone a final screening to ensure they are speed-optimal, with most algorithms being RU and RUD. The movecount statistics (generated over 250,000 solves using the algorithm for each case as mentioned in the spreadsheet; hence note these are speed-optimal stats, not move-optimal) are given below:
| TDR variation | TDR (with pre-AUF) | ZBLL (with pre-AUF) | ABF | Total |
|---|---|---|---|---|
| Average | 10.51 | 15.10 | 1.10 | 26.71 |
| Std. Dev. | 2.00 | 2.68 | 0.60 | 3.39 |
| Median | 10 | 15 | 1 | 27 |
| Minimum | 0 | 0 | 0 | 5 |
| Maximum | 16 | 22 | 2 | 38 |
Note that these are algorithmic steps, so the efficiency of the simulation is identical to the efficiency of any solver for each simulation. The average is under 27 moves for the finish, which is roughly equal to full Mehta-OS in theory, but there are many differences between the two approaches.
First, being a 2-step finish instead of a 3-step finish allows for lesser points in the solve to pause for recognition. This is somewhat balanced out by the fact that the individual recognitions for Mehta-TDR are harder than the recognitions for Mehta-OS, and it is significantly harder to predict the case of the next step while doing an algorithm, and of course there is the lag in recall that might come at first with big algsets like ZBLL. Though, the recognition for the TDR step is easy enough to be predicted and even influenced during EOLE.
Second, the sub-27 movecount for the Mehta-OS finish is done assuming a solver that always knows the best path, which may not always be the case. Thus, in practical solve situations, this movecount is bound to rise slighlty for Mehta-OS, but not for Mehta-TDR. Also, the average TPS for Mehta-TDR is likely to be faster than that for Mehta-OS after enough practice simply because the speed-optimal TDR and ZBLL algorithms are extremely finger-friendly. To quote myself, "TDR is by far the best algset I have ever come across."
Finally, Mehta-TDR has very low likelihood of skips when no influencing is done (~0.1% chance to skip any step during a solve), while Mehta-OS has ~3.5% chance to skip one of the three steps, and ~0.1% chance to skip two of the three steps assuming no influencing. Also because it is relatively easier to influence Mehta-OS steps, it would be a better candidate for frequent fast singles.
In all, the solves using the TDR variation are fairly straight-forward, allowing the user to focus on few specific things like recognition, TPS, and EO-Ledge efficiency. The TDR algorithms are almost all sub-1-able, some being even quicker; and it is possible to look-ahead to and influence the TDR case during EO-Ledge, minimising the pause before TDR. With sufficient advanced EO-ledge techniques, it is possible to achieve sub-45 average movecounts for this algorithm-based method, which in itself is a testament to the potential of this variant.