Care to extrapolate? We tried hard to take industry use cases.

kafka/zk bug: I just don’t think this is a compelling example of an underspecified interface being to blame. In my view, it’s squarely on kafka to correctly implement its replication policy, and that likely isn’t something I’d want to bake into an interface layer at the system/network boundary. Also, kafka is a fairly foundational infrastructure-y component from a modern “serverless” perspective, and its interface w/ zk is critical — it just doesn’t exemplify the type of pain you see from underspecified interfaces in large microservice deployments. Unlike between tons of small containers, the kafka/zk interface is worth scrutinizing and warrants a ton of manual testing and verification.

lambdas/kafka: from my perspective, this one is kind of conflating the value of Options with the value of a typed IDL with some notion of generics baked in. It’s not clear to me that Option[Number] is what I’d want in this scenario, maybe I just want to reject anything that doesn’t validate to a Float — but I think that’s kind of tangential to whether or not generics in a more conventional sense would be useful.

edit: I guess I would have liked to see examples that show how this would help with discoverability, code generation, distributed tracing, monitoring, verifying large systems of microservices. It's a nice position to start with though -- are you planning on a follow up or an implementation?

Those use cases weren't super-specific. IoT sensor data gathering can be accomplished in many, many ways using a Kafka platform. I've done enough operations work to see that this would mean nothing to me (as it stands). I well laid out use case explaining what it means to developers and ops would help your case. Good luck!