I think I understand your point, and I agree that it would be ill-advised to remove the ability to change the "scope" in question from lisp's control. What I'm trying to say (and I think Yuan Fu is also suggesting) is that while emacs necessarily has *one* view of the buffer, narrowed or not, tree-sitter might want to maintain multiple trees of that buffer, with the default being the same as emacs' widened view, and narrowed views being separate parse trees created as needed. I'm suggesting this as an alternative to having emacs+ts effectively throw away most of the parse tree every time the user narrows, then have to re-build it on each widen.
In other words, I think this might be a communication issue about the default trade-off behavior: generally keep a fully-widened tree and create/use narrowed trees as needed, versus generally keeping only a tree that matches whatever a higher-level view of the buffer might give at any one moment, rebuilding each time.
Hope that helps,