This makes perfect sense!

But it seems that introducing new interfaces might be unnecessarily complicate this KEP; and it might be better to consider it as a separate KEP.

there's no new interfaces, we're referencing interfaces defined within gogo packages currently ... we're redefining those interfaces locally instead

Sorry I got to this post-merge. Wanted to share what Istio is doing with k8s APIs that may be impacted.

We use an attempted cast to gogoproto.Message to determine if an object is a Gogo message, which uses ProtoMessage(). From there, we use it to...

• Call gogo.MarshalAny (I think this can be replaced with a call to Marshal() ([]byte, error) directly and then handling the Any construction
• call gogojsonpb.Unmarshal (this doesn't seem great anyways and can just use json.Unmarshal?)
• Call gogoproto.Equals() -- for this, I don't see a clear replacement?
• Call gogoproto.Clone -- I don't think the generated DeepCopy methods are a suitable replacement because the deep copy methods are like DeepCopy(T) T which means if I have an any I cannot deepcopy it(?)

• Call gogo.MarshalAny (I think this can be replaced with a call to Marshal() ([]byte, error) directly and then handling the Any construction

calling one of the self-contained Marshal* methods is definitely recommended over calling the gogo or standard proto marshal methods

• call gogojsonpb.Unmarshal (this doesn't seem great anyways and can just use json.Unmarshal?)

proto-oriented json encoding is not recommended at all for k8s API types ... definitely use json.Marshal or json.Unmarshal

Call gogoproto.Equals() -- for this, I don't see a clear replacement?

Use reflect.DeepEqual or apiequality.Semantic.DeepEqual. proto equality rules are almost certainly not what you want for comparing Kubernetes API objects.

Call gogoproto.Clone -- I don't think the generated DeepCopy methods are a suitable replacement because the deep copy methods are like DeepCopy(T) T which means if I have an any I cannot deepcopy it(?)

DeepCopy or DeepCopyObject is what you should be using for K8s API objects. I honestly don't know what the generated clone methods do for Kubernetes API types or if they are correct at all. Do you have pointers to where you are copying arbitrary Kubernetes API types not known at build time using proto.Clone()?

If you want a single method you can test as an interface, I'd recommend DeepCopyObject() runtime.Object

func DeepCopyObject[T runtime.Object](obj T) T {
	return obj.DeepCopyObject().(T)
}

Talked offline, DeepCopyObject would work for top-level objects, but doesn't work for substructs, which istio sometimes copies. Hoisting recommendations from that thread:

• if there's a set of specific known types you're copying, I'd probably type-switch a concrete set you actually use along with DeepCopy
• if you can limit copy use to top-level runtime.Objects, DeepCopyObject could work
• otherwise you could make a helper method that uses reflect.MethodByName to call DeepCopy and then cast, but that kills dead code elimination, which isn't great

As discussed on slack https://kubernetes.slack.com/archives/C0EG7JC6T/p1759867608433149, Istio is able to immediately move off all of these dependencies so will have no issues with any of the changes presented here. Thanks @liggitt