In fact, Context Tagging does restrict symbol searches and references to the appropriate scopes, whenever possible.
However.
There is a problem with nearly all C/C++ code: preprocessing. Seemingly innocuous little macros like "MY_CDECL" or "MY_PACKED_STRUCT" or "MY_EXTERN_C" or "MY_NAMESPACE_BEGIN(ns)", "MY_NAMESPACE_END", or "MY_USING_NAMESPACE(ns)" turn what could be beautiful C++ into gibberish as far as our parser is concerned. The solution, as always, go to Tools > Options > Tagging Options..., click on "C Preprocessing..." and define your macros so that the parser can deal with them.
There is also a problem with some people's C/C++ projects: They are missing the header files, or third party libraries in their workspace, so SlickEdit is left with incomplete symbol information.
So, right there are two solutions to making Context Tagging and References work more effectively for you, but let's look more closely at your example and the potential failure points:
something.length();
So, you want to jump from "length()" to it's definition? To do so, SlickEdit has to find:
1) the declaration of "something"
This could be a failure point, if there is preprocessing around the declaration that turns it to gibberish. This is also a failure point if you are coding in a silly scripting language where you do not declare variables -- if so, the choice of programming language has crippled your editor.
2) the declared type of "something" -- let's say it is "SomeThing_t"
Again, prepreprocessing could cause this to be a failure point. Or, if you are using a language where you declare variables but they are all essentially typeless containers (like JavaScript) -- again, the choice of language cripples your tools.
3) the declaration of the "SomeThing_t"
Again, preprocessing could be a problem. Also, if SomeThing_t is declared in a header file that is not in your workspace, this will be a failure point.
4) the declaration of "length()" within Something_t, and it's definition.
Again, preprocessing could break this. Also, if length() is inherited from a superclass, SlickEdit has to follow the inheritance chain to find it.
---
PS. You may ask why doesn't SlickEdit just do full preprocessing like the compiler does in order to solve some of these parsing problems? The answer is performance and simplicity. To do full preprocessing you need to know the exact header file search path, as well as command line #defines, and built-in #defines. Right now, context tagging works really fast with minimal setup for most code. Based on that, the current solution is a very reasonable compromise.