It's unclear to me why the String method is not good enough.
The only time it would differ is if someone were intentionally trying to break the comparison.
Doing a deep equal on location would require comparing not just names but also all the many transition moments where the location flips from, say, EST to EDT or back. That's a bit heavy.

My usage for it was I'm writing a library method that returns the Location for a given call, and I wanted to test it, and my naive test on == wasn't working.

Partly, I was surprised that when loading the same location twice, they weren't equal just using ==. I had sort of assumed it would have returned the same thing for the same request, but it looks like it loads from scratch on each call, so the pointers were not the same.

Then I thought, stepping back a bit, what if I used any other library that was written by a malicious or lazy programmer. It would return a Location, but I have no idea if it's returning "true" (e.g. full IANA tzdata transition history, etc) data, or if it was just faking the return with a Fixed Zone that is maybe close enough (LosAngeles being always PST and no PDT), or they were just being mean and return rand.Intn(24)-12. If that was the case, I couldn't just trust String() to be a safe enough check. .

For my case, I trust my code to return the known time.Locations, so using String() suffices for my current case. I was more making the feature request as a search for a longer term robust solution. If you want to close it out or set it as a down the road nice to have thats okay for me.

The alternative for this specific case would be to make LoadLocation cache things it has returned and return them again. That would fix == on two different LoadLocation("LosAngeles"). But it would also require keeping those around forever, which gives me pause. Probably no program would ever load too many distinct locations, but especially with LoadLocationFromTZData (which would have to do the same caching), it could in theory be unbounded.

There just doesn't seem to be a nice clean obvious answer here. Combining that with there not being an obvious need, it seems like we should sit this one out and do nothing.