I think it's worth spelling out what's going on here. In my view, it's part of the natural transition from "problem orientation" to "solution orientation".
On the one hand, you're absolutely right: solving the problem you mention is very much in scope, and should be part of the overall initiative.
On the other hand, when it comes to design, there's a danger of "scenario solving": designing a feature too specifically to a particular use case. That can lead to global designs that don't scale well, or have lots of inconsistencies.
So, when we set out to solve a problem like "allowing owned values where references are expected", we need to simultaneously keep our eye on the prize -- the full set of problems we want to solve -- and yet make sure the design we do fits into the broader context of the language.
What people have realized on this thread is that we can:
- Extend the applicability of coercions, so that they are applied when working with functions or closures as well.
- Extend the set of coercions to include
These two things together solve the original problem. But two separate pieces of design are involved -- and in particular, the key is that we want (1) to be applicable to all coercions, not just
AsRef coercions. We set out to solve one particular, narrow problem, but found that part of our solution can actually apply to a much broader range of problems, i.e. to all kinds of coercions that you want to apply at the function/closure level.
Of course, in the end we do need to make sure that we land designs for (1) and (2) such that we solve the original problem; they're not entirely orthogonal. And that's just how the design process goes: from local to global and back, iterating until you get somewhere that solves a satisfactory set of specific problems while extending the language in a globally coherent way.