DIP1000: Walter's proposal to resolve ambiguity of ref-return-scope parameters

[Dennis]

5 months ago I described an issue with `ref return scope` 
parameters:
[DIP1000: 'return scope' ambiguity and why you can't make opIndex 
work](https://forum.dlang.org/post/nbbtdbgifaurxoknyeuu@forum.dlang.org)
(N.b. in struct member functions, the `this` keyword is a `ref` 
parameter)

The gist of it is that the `return` keyword both appears in 
`return ref` and `return scope`, but currently the parser doesn't 
look at the ordering of the `ref` `return` `scope` keywords, so 
the decision is made by this rule:

- If the function returns by `ref`, it favors `return ref`, 
otherwise it favors `return scope`.

What if you want to [return a slice element by 
`ref`](https://github.com/atilaneves/automem/blob/8f61747f437b7624ad4b44085e9525fc143a9e6c/source/automem/vector.d#L209) or [return a `ref` as a slice](https://github.com/dlang/druntime/blob/dded4c2b561784f71de88be433d6e2186ec7eeee/src/core/internal/convert.d#L804)? Tough luck.

But wait, that rule is only what the specification says *should* 
happen. dmd actually has its own ways of choosing between `return 
ref` and `return scope`:

> Consider the following types:
> 
>     P contains indirections
>     I does not contain indirections
>     X may or may not contain indirections
> 
>  Currently, the ambiguity is resolved:
> 
>   a. P foo(ref return scope P p) => ref returnScope
> 
>   b. I foo(ref return scope P p) => returnRef scope (!!)
> 
>   c. ref X foo(ref return scope P p) => returnRef scope
> 
>   d. X foo(ref return scope I) => returnRef (!!)
> 
>   e. ref X foo(ref return scope I) => returnRef

Walter describes this existing behavior, as well as a proposed 
solution to explicitly allow the missing cases, in this bugzilla 
issue:
[Issue 22541 - DIP1000: Resolve ambiguity of ref-return-scope 
parameters](https://issues.dlang.org/show_bug.cgi?id=22541)

What do you think of this proposal?