By Third-party ViewHelper scopes I just mean namespaces that aren’t part of TYPO3 - for example, extensions like VHS. So with other words, would the tool also provide autocompletion for ViewHelpers like those from VHS, when VHS is installed. It sounds like the answer is yes. This also relates to my question about template pre-processors because it is actually a template pre-processor that is responsible for extracting a namespace definition from xmlns - there are three built-in processors (https://github.com/TYPO3/Fluid/tree/main/src/Core/Parser/TemplateProcessor), but in addition to those, TYPO3 allows you to add your own which might do different things. The thing about those template pre-processors is that you don’t actually know what they do (which effect they have) until you execute them - and they can change how the template is parsed and executed. By far the most important one would be NamespaceDetectionTemplateProcessor which extracts and registers namespaces defined with xmlns - without this, the information about which PHP namespace belongs to a certain Fluid namespace might be lost.
Very important detail: the global array that contains Fluid namespaces is not the only way a Fluid namespace can be registered so it isn’t sufficient to respect those namespaces! It actually needs to be done on a per-template basis and ideally has to happen by triggering the namespace detection pre-processor and let it add detected namespaces to the ViewHelperResolver via RenderingContext.
And the Expressions are a similar feature. There are some built-in expressions: https://github.com/TYPO3/Fluid/tree/main/src/Core/Parser/SyntaxTree/Expression (Math, Ternary, Casting) which you trigger e.g. with {variable + 1} - those are similar to the template pre-processors in that you don’t actually know what they do, until you’ve triggered them - and any TYPO3 extension can register additional ones. You can see in this factory the two additional global configuration arrays that are used to hold such third-party pre-processors and expression types in https://github.com/TYPO3/typo3/blob/main/typo3/sysext/fluid/Classes/Core/Rendering/RenderingContextFactory.php#L58.
It would be a challenge to support those and provide for example auto-completion and syntax validation for those things that are provided by them, and to take into account how they might change how a template is parsed and rendered (for example, those two that add namespaces might change which PHP class a given ViewHelper points to). And I was wondering if those things are on your radar because without them, an LSP tool for Fluid would be quite limited in usefulness.
Merged ViewHelper namespaces: yes, that’s exactly what I meant. If the LSP extension is truly within a real TYPO3 context that shouldn’t be a problem. I would then suggest using the ViewHelperResolver to convert a namespace prefix and ViewHelper name to the FQCN of the PHP class that handles it (assuming you also did something to trigger the pre-processors which register the Fluid namespaces so the right FQCN is resolved).
Template pre-processors: You’re absolutely right that it’s probably not going to be possible to provide auto-completion for those - although it would make sense imho to hardwire auto-completion for the built-in ones at least, to assist with writing namespace registrations and to disable further validation and auto-completion of the passthrough pre-processor, {parsing off} is used (since this makes the template valid and un-handled even if you use broken ViewHelper syntax in it).
Click-to-navigate: Good to know it’s on your list, because that would be a very useful feature. I’d even say that a first iteration which just shows every potentially matching partial would be useful. I was just wondering if that was something you were also considering - and now I see that you did 
As a final note, I think the answer to Simon’s second question in the start may actually turn out to be “yes” if the LSP tool is to cover the things I’ve mentioned here. Some parts may need to become public which currently aren’t - other parts may need to be formalised a bit more (expression types to document their supported and matched expression formats - template pre-processors to document which strings they would match and replace).
