CC @pjweinb

In
package whatever type B func() type C = func() func Run(a func(), b B, c C, bb ...B) { a() // a is called a function b() // b is called a parameter, but it looks like a function c() // c is called a function for _, f := range bb { f() // f is called a variable, but it looks like a function } }
bi is called a parameter, even though it is used like a function, because its type is B. It can be used as a function because its core type is func(), a function type. The Go type checker identifies a and c as functions, and b as an identifier.

So the question is what 'semantic' in 'semanticToken' means. Here it could mean 'used like a function so call it a function' or it could mean whatever the Go type checker thinks [which for b, is that it is an identifier that was a parameter, and for bb, that it is a variable]

I'm inclined to leave it the way it is. The user can see (even without semantic tokens) that these identifiers are all being used to call. The semantic tokens give some information about the types: b and c have different types, even though their underlying types are both func().

By @pjweinb talk, I think the main point is "a function type-alias is not identified as function by Go type checker". So it looks like the issue is not about semantic token.