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,
~Chad