I understand your concerns. It should not have happened.

Are other languages special casing this to keep it around and not introduce a breakage?

It was caught by JS during update, and only a few languages got affected. Java has additional filters that prevented.
We'll have a more reliable filter in weaver - open-telemetry/weaver#569 for this.

It hit c++ the worst since semconv are part of stable otel api package - open-telemetry/opentelemetry-cpp#3251

---

I think instances like this make us wary for making semantic convention packages stable (which as @aabmass mentioned above we were thinking of doing since we have stable/incubating namespaces.

Java goes stable with semantic convention (stable) artifact.

We fixed the problem in semconv - stability is now required. And this specific issue should not happen again.

From python side, we should review public API more carefully in a stable artifact. Of course small unintentional additions could slip in by mistake. I hope it won't happen again, but if it does, we can still use an escape hatch like this one open-telemetry/opentelemetry-cpp@main...lmolkova:opentelemetry-cpp:workaround-network-interface-name (or what we've done in the past keeping removed attributes hardcoded in jinja templates)

---

So I think if you want to release stable semconv, we should make sure we have public API checks in place and in the worst case, if something extra gets in, we'd have to keep it around. Let me know if you have any thoughts on how we can harden it further. I'll also bring it up in semconv call on Monday.