I work in projects where this could be helpful, but even I had to think for a few minutes to get how this could work. So here is a sample scenario (of my interpretation of the request) to help SlickTeam grok it:
Another way to look at this is not just a Smart Open feature request, but also a Symbol Search filtering request.
I work in projects that have anywhere from thousands to hundreds of thousands of source files. The larger the project gets, the more likely there will be symbol reuse across different subsets of the project. And some method names are inherently prone to having many copies (e.g. AddRef, Release, Find, etc). And often the majority of matching symbols are from esoteric subsets of library sources. If only I could somehow give a hint that I'm only interested in seeing symbols from a particular folder or project or wildcard, then instead of getting a matches list so large it's been truncated and doesn't contain the symbol instance I care about, I could get a more relevantly scoped list.
E.g. when I want to look up AddRef in the Symbol Search window, it finds so many matches that it truncates the list.
If I know I'm only interested in files under the Gromwidget subproject in the Ubersoftware project, I could type "gromw" in a path filtering box, and the list could magically shrink to the 9 relevant symbols.
Taking it further (and maybe easier to implement, too)
What would be really automagical would be if SE could somehow infer my intent and list matches more relevantly to begin with, without requiring any additional manual filtering.
To that end, maybe the sort order could be enhanced. Instead of listing all matching symbols in alphabetical order, what about listing them in order of scope: Local, Project, Workspace, Compiler? The list could have a header for each scope section, and then list the matching symbols beneath the header in alphabetical order, followed by the next scope header, and so on.
Perhaps smart scoping could also be used for Ctrl+Space auto completion. Too often I'm trying to type a local variable name or a member with implicit "this" scope, and SE seems to favor the first alphabetical match, which is usually some esoteric symbol somewhere in a library I never use from some header in the compiler tag file.
I realize I'm probably oversimplifying and there are dodgey details to work out, but it would be great if SlickTeam can think a bit about how to enhance the intelligence behind which symbols are favored in auto completion situations. I suspect that scope could be a useful differentiator, but maybe are other differentiators that could be good instead/additionally.
(All with the usual caveats about having options so it can be configurable and not wanting to change the defaults and unexpectedly alter behavior for users accustomed to certain behaviors, etc).
