There's a few finicky differences. I'm still of the understanding (and I may be wrong, still mystified by some of D's more complicated template syntax) that once you give the returned tuple a name, it is structurally bound to the stack. At that point, passing any member by-ref to any function must conservatively commit the entire tuple to the stack. This behaviour won't be intuitive to most users, and can be easily avoided; by obscuring the Tuple from user visibility, they can only access the returned values through their independant output assignments, which guarantees the independence of each returned item.

Syntactically, scatter can't declare new variables inline (?), it also uses additional lines of code (1 + as many variables as you need to declare), which is very disruptive to flow. Maths-y code should be un-cluttered and read sequentially. Having to put extra lines in to munge un-related things really ruins the code IMO ('t' is of no consequence to the user, pollutes their namespace, gets in the way with extra lines, etc).

What people want from MRV is to capture the returned values independently. If I wanted to capture the returned Tuple (the extremely rare case), I'd rather do that explicitly, something like this:

auto t = tuple(mrvFunc());

scatter/gather is nice and simple, I'll take it in the mean time, but I think it would be a shame for it to stop there longer term...

That said though, it's all still nothing to me without at least a promise on the ABI :) .. And I feel that should ideally come in the form of a language policy/promise that this feature will be 'efficient' (or at very least, not inefficient as it is now), and leave it to compiler implementations to concur with that promise, ie, failing to be 'standards' compliant if they fail to do so.