From @jack-berg's Comment on #4286, we should address the following:
Should we extend an interface, even when its allowed? Extending interfaces is easier in some languages than others. Ideally we get it right the first time (and we should strive for this), but in the event we don't, when does the value of extending an interface trump the friction it causes in the languages where they are hard to extend? This is related the "be stable" value, but not entirely captured.
Language implementation or collector. We often have proposals for use cases that could be done in the collector, but could also be done in the SDK which is advantageous to some users who don't want to use the collector (or in some cases can't). Given that spec API / SDK features need to implemented 11 times, when is it appropriate to reject a API / SDK feature proposal that can be accomplished in the collector? Doing so can help us focus on more pressing problems, and potentially simplify user story by reducing the number of ways to accomplish the same thing.
Plugin extension point or structured config. There’s a trade off between SDK plugin extension points (i.e. exporters, processors, samplers), and a more limited or structured approach (i.e. exemplar filters, attribute limits). SDK plugin extension points offer more flexibility but generally have more cumbersome and less standardized configuration. Reducing flexibility (or adding guardrails) can add safety and improve UX in certain domains. When do we choose one or the other? This is related to the "be simple".
From @jack-berg's Comment on #4286, we should address the following: