I'm not sure what you mean by "tokens not being a finite set". I suppose there's the theoretical issue of token length being potentially unbounded, but whatever problems your editor has with that, your lexer will likely also have. For any finite length file, there is a finite number of tokens, and once you parse it, you've got a much smaller list of symbols plus a convenient address for each one. I don't think it's a practical issue.
Vim's understanding of tokens makes some reasonable assumptions, but unless you've configured the textobjects plugin to talk to a properly configured language server, you're working on vim's presumed tokenization and not a tokenization that's native to whatever the underlying language is. Helix tries to bundle this in by default, but it still doesn't feel like a first class citizen.
As for turning machines, not since the 80's have the tokens that appear in our editors been the tokens that are manipulated by our processors. There are typically a myriad of bytecode translations or compiler optimizations or parser hijinks between what you're editing and what you're running. It's the AST that matters to the code author, and the AST is a tree, not a string.
We need to get to the point where you can directly annotate on a function parameter:
> this function is slow when this parameter is > 100
...such that the annotation sticks to that parameter, however the viewer has chosen to render the text.
The best we can do at present is to sprinkle some text nearby leave the problem of deciding which parameter and which function are referenced an exercise for the reader. This then necessitates that we preserve the way the text appears, which prevents us from presenting it differently based on the view context (e.g. maybe the reader prefers different units, timezones, or a language which flows their text differently than the author).