Short (but useless) answer to your question: No, it does not in general break the "scope".
As with everything else, there are cases in which forcing immutability is good and cases in which it isn't.
Some cases are blacker or whiter than others of course. Your example is a candidate for when you might not want to force this on the invoker. However, you may be returning a Collection and while only created locally, you may have a case where this collection is a special-purpose hand-built beast. And that beast just happens to have abysmal performance when you modify it, so you may want to protect your users from having to know this fact by simply prohibiting modifications.
As @Bwmat pointed out, another typical scenario is providing access to a member attribute collection. Normally, you do not want that to change outside of your class, so you lean towards immutability. But that's no silver bullet either. Sometimes your callers run in a different thread and simply iterating over that collection may cause a ConcurrentModificationException, so you decide to return a copy instead. In even rarer cases you may even feel compelled to return the actual collection (though that is pretty darn dark area now).
As you can see from these examples, the discussion often includes both sides' behaviors - the method declarator's side and the client's side. The very term method scope used in your question is ambiguous and that may be at the root of the issue here.
We have the strictly lexical method scope as used in the compiler domain. It's the part of your code in which those arguments and local variables of the method are accessible. Obviously, this scope is not meant here, since looking at the method caller is clearly outside of it.
The method scope of an interface method though reaches far beyond that to all points at which the class loader can potentially access the interface. In other words, it is part of that scope to consider invoker usages of your method and its return values.
Finally, you may define an entirely different scope for your method in the area of your problem domain (as in the "string tokenization scope") and you may come to yet another solution on what the best return type should be.
In summary, be aware of what your method's scope actually means to you and your team and as usual, weigh the pros and cons of each approach within that scope.