one more other question: how should classes defined via metadata (but not class hierarchy) work? Example case: I have a processor that generates an adapter for a sealed class and references all of its sealed subtypes. I've treated it as basically "isolating" up until now because we could get all the information from the original sealed class

In general, if you get elements through metadata rather than KSP's API, you'll have to tell KSP by adding the corresponding sources. However, the only way to get a KSNode is through KSP's API. Therefore you either get them by Resolver (and need to associate them with relevant outputs), or through other KSNode. If what you get is, for example, a KClass, then it is completely out of KSP's control. You'll have to associate the files that contains all the information you used manually. In the case of sealed class, if you get the sealed class via KSP, you don't have to do anything on the subtypes, because sealed subtype must be defined in the same file with the supertype.

for now yes, but fyi that that limitation is going away with the introduction of sealed interfaces

In that case I think we either need to add something like

getAssociatedOutputs(source: KSFile)

so that this can be implemented on top of rest of the API, or simply provide

getSealedSubclasses

, which would be similar to

getSymbolsWithAnnotation

getSealedSubclasses() would be super useful 👍. Right now I just do it like this: https://github.com/ZacSweers/MoshiX/blob/main/moshi-sealed/codegen-ksp/src/main/ko[…]csweers/moshix/sealed/codegen/ksp/MoshiSealedSymbolProcessor.kt

Filed a tracking issue: https://github.com/google/ksp/issues/218