Part of the problem here is that what `scope` means is not well-defined. _All_ the spec says on the matter is "references in the parameter cannot be escaped (e.g. assigned to a global variable)". I don't believe that it even talks about `scope` affecting closures. You get the basic idea of what `scope` is supposed to do but not the specifics. And based on what TDPL lists in its index, as far as I can tell, it doesn't discuss it either.

The _only_ thing that I am aware of that is fully agreed upon that `scope` is supposed to do (and the only thing that is even partially implemented for it) is to make it so that a closure is not allocated when a delegate function parameter is marked with it. And I don't believe that even that is fully implemented.

There are plenty of folks who assume that `scope` should impact `ref` or arrays or your ability to take the address of a parameter or something that it points to, etc. But AFAIK, there is no official word or decision on any of that. And given Walter's aversion to flow analysis, I don't know how we could _ever_ implement `scope` properly even for delegates, let alone anything else. As far as I can tell, fully implementing `scope` (especially if it involved all types rather than just delegates) either requires fairly advanced flow analysis or makes it so that you can do almost nothing with the parameter, because the compiler can't guarantee that you're not doing something which makes it or anything it refers to escape the current scope.

So, honestly, I'm inclined to argue that the only place that `scope` should be used at this point is delegate parameters, and that `in` should be used absolutely nowhere. We don't even know for sure what they're supposed to do, and if/when they're finally implemented, there's a high chance that we'll have used them incorrectly, so using them just increases the odds of breaking code later.