The second one has plagued me with a couple kubernetes clients I've written, but something about your restatement of the problem struck me with (IMO, of course)

The second one has plagued me with a couple kubernetes clients I've written, but something about your restatement of the problem struck me with (IMO, of course) a nice idiomatic solution: a "debounce" fan-in (ish) channel between the ResultChan() and consumer that bundles up watch notifications after some configurable wait period. And actually, it's a common enough use case (I'd definitely use it too) that I'll bet it would be useful to have in client-go itself. And secondly, I would love to see this kind of concept upgraded to a first-class citizen in kubernetes. Essentially, I think an equivalent of `/etc/environment` for your cluster would be a powerful way of generalizing app components. It would be great if just placing resources in your cluster allows them to pick up at least some of their required configuration, much like customizing `/etc/environment` does for *nix machines.