We're not clearing this in prepareCandidate(when feature is disabled) ?

Currently, we are.
But, as mentioned in #128067, I have to think a bit more about it through the weekend.

Alright, I missed L455 in this pr before, I thought we already removed it in this pr😅.
But we should clear nominatedNodeName for low priority pods after preempt success, no?

We should do before.
Because after the moment the high priority pod gets nominated to the node, lower priority pods could be unschedulable, regardless of whether the API calls are completely done or not.

But, I still believe we don't need to clear nominated node names of all lower priority pods on the node.
Because, for the extreme example, if high priority pod only requires 2 CPU, and there are 10 lower priority Pods that require 2 CPU each and have already got nominated to the node, it doesn't make sense to remove the nomination from all.

So, I do believe we should seek other way like:
#128067

But, I'm considering such enhancement separated from this KEP (i.e., no need to implement it together), and thus I wouldn't like to include the change here.
I was thinking I'd pursue when I've got time after Kubecon. (... or you can take over if you want! :))
Also, either way, I believe that kind of scenario (there's a lower priority pod that just completed the preemption on the same node) is fairly rare, and hence we needn't actively prioritize it.

I'm +1 for separate it from this KEP, it will be easily to roll back if sth goes wrong after the implementation.

... or you can take over if you want! :

I’ll look into this when I have some free time, but I haven't thought of a good solution yet also :(

The rough idea that I have is like:

• When calculating the victims on the node, we assume the nominated Pods are on the node already.
  • Lower priority nominated Pods could be selected as victims, while higher ones shouldn't.
• Then, if lower nominated Pods are selected, prepareCandidate (or prepareCandidateAsync) unnominates them instead of deleting them.

So, in short, the nominated info on lower pods will be un-nominated only when necessary.

But, apart from that idea, I'd like to still seek the simplest option like #128067.
We have to think thoroughly if there's any corner case though, maybe we can just do that.

It would be good to consider how Autoscaler handles nominated node before taking the decision to remove this logic. If some of the low priority pods no longer fit the nominated node, Autoscaler should be aware that it needs to still consider them in simulation in other places, but not necessarily tied to this particular node, which would be overallocated.

Another argument for keeping this logic is that such overallocation would block scheduling of even lower priority pods which could fit. If unominated pods still fit, they could be still scheduled in the same place. The only worry is potentially unnecessary ongoing preemptions would be wasted and the risk unnominated pods won't reschedule, but not sure about it yet.