The top-level goals are listed at the beginning of this thread: Kotlin Serialization
Answering your specific questions I can add here, that we don’t see any reason to spend our time to make a better/faster framework for JVM than Jackson/Gson. Our primary driving use-case is isomoprhic Kotlin, e.g. a common Kotlin code that works with the same semantics on all Kotlin backends (JVM, JS, Native). We don’t have Jackson on either JS nor Native, so there’s nothing be better/faster there.
Moreover, we don’t want to limit ourselves to any particular serialization format or even a family of serialization formats. We are not working in “JSON Information Set” (if you excuse me for using this term) like Jackson, but in “Kotlin Information Set”, e.g. we take Kotlin’s type system and present Kotlin’s objects and their elements to the library that is going to map the corresponding information set into whatever output format. Basically, Kotlin Serialization framework simply provides Kotlin’s object-traversal facility.
A very important use-case that we have is not directly related to serialization or even JSON for that matter. It is about loading Kotlin objects from databases and configuration files. E.g. our main goal is make it possible to do it all without reflection, since we don’t plan to support reflection on either Native or JS backends in the near future.
As for JVM beans, yes. JVM interop on JVM backend is a very important piece of Kotlin’s story and we do plan to support JVM beans in some way.