StaticType extensively used Kotlin’s data classes which provide many convenience methods such as copy and destructuring declarations. However, the convenience of data classes makes it hard to add new fields without breaking public APIs. The guidance from the Kotlin documentation is to not use data classes in the public API.

A similar issue applies to sealed classes/interfaces and enums which we cannot easily add new variants without breaking existing customers.

Due to how we modeled types and union of types, all types in 0.14 are non-null and non-missing by default. In many typing scenarios, we often deal with nullable and missable types. A nullable type was represented in 0.14 with a unionOf(<type>, null). This modeling was complex and prone to error as users would have to remember to omit a null or missing type from a union before working with the type.

StaticType 's modeling as a set of classes and interfaces was tightly coupled to Java/Kotlin’s class semantics. This made certain operations such as extracting constraints complicated and involved a lot of additional casts to users' code.

StructType, the representation of a struct in StaticType, had a messy modeling with potentially contradictory constraints and unused fields. StructType defined a contentClosed field as well as a separate TupleConstraint.Open constraint which represented the same thing. This required users of StaticType working with structs, to ensure both the field and the constraint are properly set and do not conflict. There was also a primaryKeyFields that was not used in the library, adding further overhead to the public API.

0.14 allows users to define unions of arbitrary types using the AnyOfType. However, this required users of StaticType to constantly ensure the types are properly normalized using the .flatten() method.