I'm going to be a bit boring and also say "stability", in particular interface stability with respect to forward compatibility. From my perspective, this boils down to a couple things:
- The implicit interface between Kata and the contained workload -- if I take a given workload that uses a fixed feature set and run it under two versions of Kata, the workload should observe an identical execution environment at a POSIX/Linux ABI level. This includes filesystem paths, device paths, network device interface names, etc. Workloads shouldn't take dependencies on these things, but in practice users will create implicit contracts and expect them to be honored. It causes user pain when these things change, which in turn causes operational pain for cluster owners trying to upgrade their infrastructure (be it in a public cloud or a private on-prem installation).
- The explicit contract between Kata and the on-host orchestration -- a lot here comes from being OCI-compliant, and additional convergence seems among the most valuable things for the project overall, but as others have observed the real surface area is larger. Upgrading Kata within an existing orchestration environment carries similar risks to upgrading Kata around a pre-existing customer workload -- cluster operators will inevitably integrate with any API surface made available, whether or not it is declared to be stable.
I would generally put features that address a larger and more diverse set of workloads at lower priority than avoiding regressions for existing workloads. Workloads that are already broken can be frustrating, but at worst they carry an opportunity cost. Breaking running customer workloads across releases (even via a breakage in an implicit rather than explicit contract) causes operational churn in the immediate term, and in the long term it causes a support burden for the Kata community: operators continue using older versions to support existing workloads (whether out of real or merely perceived fear of regressions) and the Kata community ends up with an unwanted long-tail of releases where good community stewardship mandates backporting security fixes, etc.
Providing a stable surface area as a first priority and then expanding it in compatible ways allows operators to stay closer to "HEAD" (and in some cases simplifies the maintenance of long-term stable releases).
As for how to get there, that comes down to policy, best practices, and verification as part of CI.
Jon