idempotent/soft customElement decorator

Description

We at Vonage using the Lit library as both a stand-alone and as part of MWC components, we are building on
There are cases, see TLDR, actually always, that we need customElement decorator to behave in somewhat-idempotent fashion: define an element only if there is no such an element defined in the registry
See TLDR below
defining the component named my-component twice won't throw

Defining the component named my-component twice won't throw

The below assumptions are leading to an issue with current, strict, customElement decorator behavior:

when someone delivers web-component to the world, it is a usual practice to perform the actual component definition/installation/registration as part of the immediately invoked component's module flow (this is what MWC do as well)
it is not possible today to manage scoped custom element registries and the spec discussion on that topic seems to be a years from now till some practical resolution
when even the same component imported form different locations it'll attempt to register self more than once and the whole dependee module init fail
it is not convenient / possible to enforce importing the component form the same location (URL specifier) in cases when different parts of the application delivered / built separately (micro frontends approach as an example)

Downsides (tolarable from our POV, but probably require attention from your side as a platform):

different versions of the component may be not deterministically defined at runtime

If the non-deterministic downside is a major concern, the decorator may:

by default NOT allow soft skip over
allow skip over as opt-in as a decorator's init function parameter
allow skip over as opt-in + warning in console / callback to the consuming application to perform decision at each point (might be lesser and future priority, when the skip-over behaviour found useful, if any).