Since Clang 3.8, libclang began exposing an CXCursor_TypeAliasTemplateDecl cursor as a result of work done by a KDevelop developer. Ironically, this feature was never actually integrated into KDevelop's clang support, and because of how cursors are dispatched in clang's DUChain builder, the default action is to recurse into any cursor enumeration not explicitly listed. This, in turn, recurses into CXCursor_TypeAliasTemplateDecl, and while that does eventually pick up a child CXCursor_TypeAliasDecl cursor, ensuring that the declaration is added to the DUChain, the foremost descendants of CXCursor_TypeAliasTemplateDecl tend to be template parameters, effectively leaking these parameters into the surrounding context.
Moreover, since the addition of CXCursorTypeAliasTemplateDecl, references from CXCursor_TemplateRef point directly to these cursors which, unfortunately, have a spelling range which covers the using keyword that introduces the name which will refer to this alias, but not the name itself. Additionally, unlike typedef cursors or CXCursor_TypeAliasDecl, CXCursor_TypeAliasTemplateDecl yields no useful information about the type it is aliasing; interestingly, CXCursor_TypeAliasDecl provides this information without fault, even if it refers to templates with template parameters. Ultimately, this means that the actual CXCursor_TypeAliasTemplateDecl cursor, for the moment, is good for little more than signalling the beginning of a new context to capture template parameters and possibly new types, and the actual, declarative unit is still a CXCursor_TypeAliasDecl cursor. Sadly, this means the procedure for building uses from cursors needs to be tweaked so lookups will make the correct association (they presently do not). Ultimately, the real fix should be in investigating the upstream implementation of CXCursor_TypeAliasTemplateDecl to see if it can be made to function more like a traditional declaration cursor.