Not sure how easy this will be to fix, but TypeScript doesn't seem to have this problem. We should be able to identify functions from the parens?

Isn't this because capitalization implies a Class name instead of a function?
That's the convention; but you don't have to follow it. If we were using the data from the analyzer, I'd expect they would be coloured correctly (based on actual AST, not guesses based on casing) so ideally we should be the same (whether it's reasonable or worthwhile, I don't know.. maybe we should just hope for https://github.com/Microsoft/vscode/issues/1967!)
Looking at this again on a whim, maybe we could assume that any ambiguous capitalized object that is followed by parens but not preceded by new or const is a function.
class IsClass {}
void NotClass(){}
var x = new IsClass();
var y = NotClass();
But that still won't help when assigning a function to a variable.
someObj.callback = NotClass // There's nothing here to detect from.
Additionally, the inverse problem is also true, lowerCamelCase class names are not treated correctly.
class alsoAClass {} // No colorizing
var z = new alsoAClass(); // Colored as a function
Seems like the best solution would be to get direct from the AST, as you said.
I think using the parens is probably the best way; seems more reliable than guessing based on case. I don't think Code is going to support dynamic colouring anytime soon :(
I'll see if I can change the regex at some point to handle this better.
Found another case where upper case is tripping up the syntax highlighting:
class FileMode {
/// The mode for opening a file only for reading.
static const read = const FileMode._internal(0);
@Deprecated("Use read instead")
static const READ = read;
...
In this snippet lower case read is scoped as source.dart but upper case READ is scoped as support.class.
@weenzeel thanks for the example. It's hard (for me) to fix some of these issues with the textmate grammar. I did hope to try and generate it from the language descriptions (in the hope it'd be accurate, including fixing the comment-highlighting bugs that keep coming up) - see https://github.com/dart-lang/sdk/issues/19298, but so far I haven't found a good way.
@DanTup I opened a syntax issue with Jetbrains and Dart SDK earlier this year. Feedback from Jetbrains was that they depended on the Analysis Server for Dart syntax highlighting. Not sure how that works or viable for VSC as well?
The Dart server provides this info, but VS Code doesn't allow extensions to perform colouring programtically:
https://github.com/microsoft/vscode/issues/585
I have seen a workaround someone made that uses the VS Code decorations API to provide the colours - it's an interesting idea, but I haven't dug into how feasible (or reliably) it would be here.
tbh if you left it the way it is, i think it's fine. Typescript tooling is unopinionated, but Dart tooling is typically very opinionated. Just my opinion. 馃槃
I would like to improve our syntax highlighting generally - we currently have a TM grammar file that doesn't accurately reflect the language and we often have bugs. Currently this is the only option for VS Code, and I don't really want to do too much more with that file - however it seems there may be some changes incoming (see https://github.com/microsoft/vscode/issues/77140). It's not clear if that will allow us to be completely dynamic (eg. delegate to the server) or it'll just be a different format. I have some concerns that going to the server may be too slow. If it is just a new file format, I'd at least like to try to generate the file from the Dart spec so that it's reliable and easy to update.
This will be handled as part of https://github.com/Dart-Code/Dart-Code/issues/2202. It works using the semantic tokens and LSP, but the API hasn't been finalised in LSP so we can't finish/release it yet.
Fixed by https://github.com/dart-lang/sdk/commit/cb2ede57b7c91fb61c0cb05971cc1823faee2086.
In order to get the fix you'll need Dart-Code v3.18.0 (a preview release should be available later today/tomorrow), be using LSP Preview, and have a Dart SDK from after yesterday (the most recent nightly works, and of course the next releases of Dart/Flutter SDKs will include this).

Due to some last minute issues, support for LSP 3.16 (which supports semantic tokens) won't be included in v3.18, but hopefully v3.19 next month instead.
Most helpful comment
Fixed by https://github.com/dart-lang/sdk/commit/cb2ede57b7c91fb61c0cb05971cc1823faee2086.
In order to get the fix you'll need Dart-Code v3.18.0 (a preview release should be available later today/tomorrow), be using LSP Preview, and have a Dart SDK from after yesterday (the most recent nightly works, and of course the next releases of Dart/Flutter SDKs will include this).