So a token.Pos does not make sense in a Fact (as it is relative to a FileSet like you mentioned). Facts need to be deserializable in another process. A token.Position makes a lot more sense in a Fact.

Will Position be too inefficient?

It depends. How many Positions are there? Vulnerable symbols could be encoding a lot of paths so without looking at the implementation it is hard to tell. If it is just diagnostics, there should not be hundreds so this should not be a problem.

The use of token.Pos in RelatedInformation implies we need to depend on a certain token.FileSet. If the positions of the related information belong to the same package, that's fine. Otherwise, it is awkward to use.

This does sound awkward outside of vet. I am not really sure what is helpful here yet. I think I might need to understand some more about how gopls is doing things before I have a strong opinion.

How many Positions are there?

RelatedInformation is only used for Diagnostics.

Propagating position info using Facts needs different ways if want to be efficient (e.g. for example, one way I am thinking is to encode file paths in package facts, use indexes for object facts, and reconstruct Position with them), but I am sure they shouldn't use RelatedInformation.

I think I might need to understand some more about how gopls is doing things before I have a strong opinion.

@findleyr @pjweinb Can you help us understand how gopls is using this related information from diagnostics?

This does sound awkward outside of vet.

To expand a bit, the reason this sounds awkward outside of vet is that {single,multi,unit}checker control their *FileSet. Which simplifies how each would use a Pos.