Thanks @jorenbroekema. There are a few things I'd like your thoughts on, specifically.

• The configuration. I could have made my own config file, and still might, but adding a custom block in package.json seemed reasonable. WDYT?
• the idea of "tokensFiles": because DTCG doesn't specify css variable prefix, I need to hold that out of band. Can you think of a better way of handling that? I could tell my users "your tokens need to have this specific, language-server-related extension", but that kind of defeats the purpose.
• Ditto for "group markers" - I suspect this is a problem in the DTCG spec though, and can't be fixed by an LS.

Other than that, please don't hesitate to file issues for bugs you find or new features you want.

Thanks again for the interest.

• Modern frontend/node based projects suffer from config bloat both in package.json and root folder. Would be nice to support at least a config file that can be placed in the root config(s) folder, but for most things I think a package.json field works pretty well (assuming they're not yet suffering from this type of bloat). cosmicconfig style is perhaps overkill in terms of customization at this time.
• It makes sense to me that the DTSL needs to know where you tokens files are in order for it to analyze and provide diagnostics/autocomplete etc. I also understand the need for a prefix at this level to prevent multiple DS with tokens conflicting with one another. Usually this is something you can handle yourself in a frontend project, but at the level of a language server, I guess you need to provide some kind of scoping mechanism. I don't really have a suggestion for something better there than a prefix.
• I feel like the idea of a token group being a group and a token simultaneously just doesn't really fly. I have worked with teams that wanted token names to be --colors-red + --colors-red-extension, and indeed, using special group markers was a clever way around it, for example just using "_" as a token group name would already kinda work in Style Dictionary, as the change-case npm lib it uses for turning the token's path hierarchy into a name filters out special characters for PascalCase and camelCase 😅 only caveat to that would be that it considers it separator character as well so you would get --colors-red-_ and --colors-red-_-extension for kebab-case I think.. not sure there, would have to double check. Again, you could work around that with custom name transforms there that handle these group markers as things to exclude entirely from the final name... that said, maybe this really should be a discussion for DTCG, it definitely is a fairly common request to have this type of flexibility in design token hierarchy semantics.

yeah lot's of is-what-it-is here, but i'm glad to hear that my intuitions pass your checks, too.