If I understand the problem correctly, just changing the imports to point to svelte/internal isn't enough because they could still point to different packages depending on how your components are bundled. It solved your specific issue, but if you had two completely unrelated Svelte components compiled to vanilla javascript bundled with Svelte, you'd still hit issues with mismatching current_component when using slots or callbacks.

It sounds like another case of multiple svelte/internal modules? I think we need to look into reworking how svelte/internal keeps track of the current component since it breaks when mixing components not bundled with the app. It sounds like we need to find a way to pass Svelte's internal runtime state when instantiating components, since slots and callbacks end up mixing different svelte/internal together.

As mentioned in #2937, this is the sort of thing that happens when you have two copies of Svelte's internal scheduler running. If you're importing the compiled version of an external Svelte component into another Svelte component, this is what you end up with. There's a svelte field in package.json that's respected by rollup-plugin-svelte and which is intended to point at the uncompiled Svelte source, so that the external component can be bundled together with the main app, without any duplicated internals.

When using the exact same Button code, the binding only works for the local Svelte module.