1. See org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.updateSupertypesWithAnnotations(Map<ReferenceBinding, ReferenceBinding>):

Updates this.binding.superclass thusly: this.binding.superclass = updateWithAnnotations(this.superclass, this.binding.superclass, outerUpdates, updates);

org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.superclass carries a comment: // MUST NOT be modified directly, use setter !

The problem with direct update is that annotated variants would not co-evolve!

To see why this is a problem, consider this code:

import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

@Target(ElementType.TYPE_USE)
@interface TA {
	
}

class Y extends @TA X {}

public class X extends @TA Object {
	
} 

After X has had updateSupertypesWithAnnotations called on it, if you inspect Y's supertype @TA X's superclass you will see Object not @TA Object

If the update was done via a setter such as:

                 ReferenceBinding updatedSuperclass = updateWithAnnotations(this.superclass, this.binding.superclass, outerUpdates, updates);
		if (this.binding.superclass != updatedSuperclass) //$IDENTITY-COMPARISON$
			this.binding.setSuperClass(updatedSuperclass);

all annotated variants would co-evolve.

2. Same method updates super interfaces but this is not problematic as the array holding super interfaces is shared by annotated variants

3. org.eclipse.jdt.internal.compiler.ast.TypeParameter.updateWithAnnotations(ClassScope) exhibits similar problems, directly updating firstBound and superclass fields which should not be set directly