In general I am not sure that is actually viable.
There is nothing that tells us that impl.A exists solely to implement X.A, it seems kind of obvious in a small example but it is not in the larger context.
Consider for example https://play.golang.org/p/YPivBBZLhZ8
Now if you rename X.A, and it renames impl.A, impl now no longer implements Y, which maybe it is supposed to do.
Also, should it rename impl2.A when there is no evidence at all that impl2 was supposed to implement X rather than Y?
I don't disagree. The only reason I tried it on the interface at all was in response to a message from gopls when I tried it on the implementation (in retrospect, I probably shouldn't have expected that to work either...).
The message from gopls was
Message: renaming this method "A" to "B" would make goplsexample.impl no longer assignable to interface X (rename goplsexample.X.A if you intend to change both types)
Maybe that message is the actual issue, directing users to try a thing that probably isn't reasonable.
I guess we should think what the ideal experience is.
Maybe when you try to rename the interface method, it should warn you about the places it breaks the code, but allow you to apply the rename anyway.
It could then look at the build breaks, and see if it could stack up some more renames that you can choose to apply to fix them again.
Is there a workaround for doing this kind of rename? assuming a simple example like the one provided: just an interface and an implementation.
Acknowledging that it may break other interface implementations?
$ gopls version
$ gopls rename -w main.go:11:13 B
gopls: renaming this method "A" to "B" would make github.com/golang/go/issues/34438.impl no longer assignable to interface X (rename github.com/golang/go/issues/34438.X.A if you intend to change both types)
$ gopls rename -w main.go:6:2 B
gopls: internal error: during renaming of abstract method func (github.com/golang/go/issues/34438.X).A() int changedMethods=false, coupled method=func (github.com/golang/go/issues/34438.impl).A() int Please file a bug report
One path forward would be to allow multiple renames in the same invocation, i.e. to allow (position, newname) to be repeated. While this doesn't necesarily make it easy to do incremental rename it does make it possible to do a complete change when the interface and implementation are completely contained to the module being renamed.