Snippets and slots interop

[rChaoz]

Describe the bug

After seeing #13063, playing around a bit and opening #13066, I've realised that interop between snippets and slots seems to be inexistent except for the default slot, which only works sometimes (see mentioned issues for details). But the docs mention about slots that:

They continue to work, however, and you can mix and match snippets and slots in your components.

The previous issue opened was a documentation issue, however I say this is a bug - it is impossible to use Svelte 4 components with slots from Svelte 5 code with snippets. It is possible to mostly workaround this, since you can use <something slot="x"> and snippets/renders in the same file, but you cannot use <slot> and snippets in the same file.

Additionally, I have a question: could there be interop between snippet arguments and slot props?

<!-- Child -->
<slot name="named" prop1={item1} prop2={item2} />

<!-- Parent -->
<Child>
  {#snippet named({ prop1, prop2 })}
    ...
  {/snippet}
</Child>

or

<!-- Child -->
<script>
  let { named } = $props()
</script>
{@render named({ prop1: "abc", prop2: 123 })}

<!-- Parent -->
<Child let:prop1 let:prop2>
  ...
</Child>

Severity

blocking an upgrade

[hmnd]

Just running into this now with a project I migrated to runes using sv migrate. IMO this should have been assigned to the 5.0 milestone @dominikg @benmccann, as it presents an important oversight in a few areas.

sv migrate migrated all uses of slots to snippets, even for externally imported components that are still built against Svelte 4. That totally breaks some key functionality for me, with no @migration-task or warning about what's going on.

Eg. I have a component that conditionally renders a Tooltip from bits-ui. I've spent an hour digging through business logic thinking something changed there before realizing the migration broke the slot passed to Tooltip.Trigger, resulting in my button never showing up. It's only caught as an error by Typescript, since the snippet in place of a prop loses it's param type.

/cc @dominikg @benmccann sorry for the tag, but I think this is should be given higher priority.