I think this is fine if you are ok with it, after all names for concepts are again a human construct. Since I am sort of interested in programming languages and the sorts of things they describe, I then look at it like so: if a symbol is not a keyword, operator or delimiter, its probably a name for something, and since we 'name' our cursors, I like to then think what sort of thing are we referencing when we type in this name (or more importantly, when whatever reads T-SQL definitions does when encountering a previously defined name), and since we've previously declared it as a 'cursor', well thats what 'type' of thing it is, ie,. this 'name' references an 'object' that has type 'cursor', ie., I'm not going to have much success assigning it an integer value. In a parallel way, 'Programming Construct' pretty much does not have enough specificity for me, although I'd not deny that there are things that we can call 'Programming Constructs'.

But this is more for my interests, I don't think you need to adopt this thought process to be successful with using and administrating SQL Server. I'm just relating why I agree how cursor could be a type and that a named entity in T-SQL could reference an instance of something that has a type of 'cursor'.

But this isn't meant as a specific criticism for you, if you are successful with the mental models and terminology that you've grown accustomed to, I don't see a big reason to change.

Well, leaving tables and cursors aside, you should at least include variables (the strings with '@' in front of them ;-)). (Of course then, we start talking about some variables having a type of 'table' and so on...)