I'm building a SwiftData migration strategy and want to confirm whether it's officially supported to reference types from a previous VersionedSchema in a newer version's models array. Setup V1 defines all 28 models under its own namespace: static let versionIdentifier = Schema.Version(1, 0, 0) static let models: [any PersistentModel.Type] = [ Self.ItemModel.self, Self.UserModel.self, // ... 28 models ] } When migrating to V2, only ItemModel changes. To avoid copying unchanged model definitions into every new schema version, I include the previous version's types directly in V2's models array: static let versionIdentifier = Schema.Version(2, 0, 0) static let models: [any PersistentModel.Type] = [ Self.ItemModel.self, // V2 type (changed) ApplicationDatabaseSchema_V1_0_0.UserModel.self, // V1 type (unchanged) // ... other unchanged models referencing V1 types ] } extension ApplicationDatabaseSchema_V2_0_0 { @Model final class ItemModel { /* updated definition */ } } Questions Since SwiftData uses the simple class name (not the fully-qualified name including namespace) as the entity name, this appears to work in basic testing. But is mixing types from different schema version namespaces in a single models array officially supported, especially when models have relationships across versions? How does SwiftData handle inverse relationships when a newly defined V2 model references an unchanged V1 model? Is there a risk of schema corruption, runtime crashes during migration, or breaking changes in future SwiftData/iOS updates? The alternative — duplicating all 28 model class definitions in every schema version — introduces significant maintenance overhead. What is the recommended pattern for handling unchanged models with relationships when migrating using VersionedSchema? The alternative — duplicating all 28 model class definitions in every schema version — introduces significant maintenance overhead. Is there a recommended pattern for handling unchanged models when migrating with VersionedSchema?