Maybe it's too early in the morning here and I'm not getting the full picture ..but I have reservations
about the "Resolve each type as an alias when possible" change as showcased in the image on the right:

1 Knowing the underlying type at a glance is valuable,
2 It presents no information that couldn't be gleaned by reading the line above it.

Is there some way in which both the alias and the actual type could be provided?

1 Knowing the underlying type at a glance is valuable,
2 It presents no information that couldn't be gleaned by reading the line above it.

Thank you for the feedback. These are valid objections! My original thought process was that since composite types like []Ast.Node.Index currently don't get translated into []u32, it would make sense not to worry about showing the underlying type of an individual Ast.Node.Index. The other option I was considering is reconstructing type strings from scratch to get e.g. []u32 but that seemed a like a lot of work for relatively little gain. However, now that I know that some people are interested, I think I'll go down that route instead.

Is there some way in which both the alias and the actual type could be provided?

Great suggestion, that definitely should be possible.

This looks excellent!

Regarding

This changes the behavior of "Go to std.mem.Allocator". Instead of opening std/mem/Allocator.zig, now it will open std/mem.zig and go to the line that has const Allocator = @import("mem/Allocator.zig");

I have no strong opinion on the matter, this is what Go To Def does as it is, and although it might be convenient to provide the choice it might get cramped.

Technically Go To Def should pop open std/mem/Allocator.zig, and Go To Decl land you at const Allocator = @import("mem/Allocator.zig");, but I believe Auguste feels strongly about this being the way it is.