You already know where I’ll land.
To me, the fact the searches are in the sidebar is a visual detail, not an implementation detail. IOW, the fact they’re in the sidebar doesn’t imply anything about their context. That’s just the most handy place to display them. (One I’m fine with, BTW.) It never occurred to me otherwise, honestly.
I expected those searches to mimic what I would do manually in the search bar. That’s what they are — searches I do manually a lot, so want to save. Why would we want saved searches to have a different behavior than our manual searches? That defeats the whole purpose of saving the search in the first place.
With the current implementation, a saved search does me no good. I never (within two decimals of never) want to search the entire file. I want to search my current project. (I admit, this is mostly because I haven’t discovered an efficient way to handle in TP what I want to do today. If I was a better administrator, I would go through all my various projects every morning and mark the things I want to do today with @today and unmark the things I marked yesterday that didn’t get done and that I don’t want to do today, and then I would have a saved search for Today, and I would want that one search to be against the entire context. But the solution for that is @searchall for that one search, not forcing every saved search to be against the entire file.)
So, I’m firmly in the camp that a saved search should do exactly what the equivalent search typed into the search bar would do with respect to context. This lets us do whatever we want with a saved search — we can search everything by setting the context appropriately, or we can search a single project by setting the context appropriately.
Now, if the current context is a single project, then I would agree that showing that on the sidebar would be nice. Currently, selecting a saved search highlights the saved search and de-highlights everything else. If the context was the current project, then showing a de-selected highlight on the project that was the context would be good. So, today, if I click on a saved search it goes blue. If I then click back in the file, then the saved search shows (in my theme) a soft grey. So, the implemention would do something like that — clicking on the saved search would make it blue and the project grey. Clicking back in the file would make the project blue and the saved search grey (because now the project was selected and the saved search was de-selected). That sounds a lot more complicated in print that it would appear in TP.
If you want to be magnanimous and give us a syntactical way of saving a search that always searches the entire file (@searchall, e.g.), then that would be extra awesome. But we don’t need that — we can search the entire file by setting the context to the entire file. (Don’t get me wrong, I’m all for something like @searchall, it’s just that respecting the context is a much higher priority. For me.)