One quite old but still open issue on GitHub about VSCode is that there's no way to find the TextMate scope at a given position programmatically. It should be possible, as the language definition is complete in that manner. Also, there are dev-tools that do exactly that.
Now, why does this matter?
I implemented an autocapitalise feature for keywords. Works, that's great

BUT! It also triggers when in block comments or within strings. The easiest way to counteract this would simply be to ask TextMate "Hey, what scope am I currently in?" and it would respond "You're in '
comment.block.cxs'" and the extension would say "Thanks mate!" and wouldn't bother to capitalise in that case. But NOOOOO the devs made it clear there won't ever be a way to interact with TextMate programmatically in that way. Sucks!
So, what does mister I-cannot-live-with-half-assed-solutions Holzchopf do? Simple! Just kidding, it's everything else but simple
First, I wrote a CX tokenizer that is actually clever enough to only re-tokenize what's necessary. This works and to my surprise wasn't that much of a pain in the rear. Why that? Well, there are multiple occasions where a readily tokenized complete file beats having the source just as text and going through the whole text to do whatever task. Over and over again.
One of these tasks is to create the document outline (a thing that already worked). When VSCode asked for the outline, the document was parsed as a whole and the outline generated from that.
I'm now rewriting so it asks the tokenizer to update the document's tokens and then builds the outline from those tokens. That's what I'm currently working on. Of course, this means completely rewriting the documentOutlineProvider. But it will actually be faster when I'm done.
Then come the other features that rely on a tokenized document. Like the autocapitalise feature. Or the F1-to-open-help. They will all - when called - just trigger the tokenizer, which will update the tokens where necessary.
Oh and also: I refactored the whole thing. Have I stated that the whole thing started as a test, whether the CX Docs were displayable in a VSCode webview? This meant the extension was kinda like built around a documentation presenter. I now properly moved the documentation presenter to what one could call a sub-module hosted by something that's worth bearing the name extension.