I think that this original plan had a bug -- and that the test should not be relying on this bug.
It eliminated "ORDER BY Tmanykeys.T_D1" which is only safe for this plan if the inner scan gets executed exactly one time -- I DON'T REMEMBER if the planner is even smart enough to recognize this, but let's assume for now that it is smart enough.
This means that the outer plan must produce at most one row.
But in this case, there is no unique index on T.T_D0, only on (T.T_D0, T.T_D1).
So, T may contain (T_D0 = 0, T_D1 = 1, T_D2 = 2) and (T_D0 = 0, T_D1 = 2, T_D2 = 4)
and Tmanykeys may contain  (T_D0 = 4, T_D1 = 1) and (T_D0 = 2, T_D1 = 3)
so we get 2 rows in the wrong order.
Am I correct to replace this original query? 
I am still a little worried that I can't connect my small fix with this corrected behavior -- why did this bad test pass bafore? why does it now correctly fail?
This isn't even a self-join and it doesn't even use aliases, so how did my recent fix change anything here?