I filed Type checker treats identical imported ObjC generic types as distinct after another file in the batch references a same-named type from another module · Issue #92419 · swiftlang/swift · GitHub with a 4 KB reproducer and wanted to surface it here since it looks like a ClangImporter regression between Swift 6.2.4 (Xcode 26.3, passes) and 6.3.3 / 6.4 (Xcode 26.6 / 27.0 / 27.1 beta, fails).
Summary: in -enable-batch-mode, if the first primary file references SwiftUI.State and the module also imports an ObjC header that has a class exported as a nested type via swift_name("Derived.State"), a later primary file fails to convert Derived to its own superclass Base<Derived.State>:
error: cannot convert value of type 'ObjCLib.Base<ObjCLib.Derived.State>' to expected argument type 'ObjCLib.Base<ObjCLib.Derived.State>'
note: arguments to generic parameter 'T' ('ObjCLib.Derived.State' and 'ObjCLib.Derived.State') are expected to be equal
Renaming the nested class to anything other than State, swapping the file order, or disabling batch mode all make it compile. It looks like the unqualified lookup of State in the first file imports the nested ObjC class through a different path than the superclass import does, leaving two ClassDecls for one Clang decl.
Practical impact: every Kotlin Multiplatform + SwiftUI app whose Kotlin classes have a nested State (the standard MVI/Reactor pattern) hits this once they move past Xcode 26.3, and the failing file changes from build to build because it depends on batch partitioning.
Happy to provide more details or test a fix.