Most efficient way to obtain a reference to deeply-nested, dynamic children?

[AimForNaN]

Say I have the following setup.

Then I do this:

<script setup>
    import App from "./App.vue";
    import Panel from "./Panel.vue";
</script>

<template>
    <App>
        <Panel title="Panel One"></Panel>
        <Panel title="Panel Two"></Panel>
    </App>
</template>

I want to obtain a reference to all the Panel vnodes so that I can dynamically switch between them when the user clicks on their tab. Unexpectedly, Vue appears to merge the slots together into a Fragment, which complicates things. Walking the fragment recursively, and constantly calling $slots.default() whenever I am presented with a default slot until I so happen to come across the vnodes that I want, doesn't seem like the best way to approach this. At the very least, it is not something I look forward to coding. There has to be a better way, perhaps even through Vue's own API, but I am unable to find any efficient alternatives.

[AimForNaN]

So, I tried taking the <script setup> approach with useSlots, and something unexpected happens. The setup script appears to get called twice: once for the fragment (which I am not interested in) and another time for the component's slot (which is what I was expecting since the beginning), which somewhat removes the aforementioned complication. But this is inconsistent behavior and creates a disconnect between script and script setup setups. Nevertheless, the script setup effect is not necessarily unwelcomed, since I end up with what I was expecting. If, however, I would have received what I expected from the beginning (what I was able to obtain in the second run of the script setup setup), complications could be avoided. But this disconnect seems like a bug to me. I don't think it is unreasonable to expect things to be ran once and to only be provided slot data that is relative to the component without being confronted with a Fragment.

[AimForNaN]

Slight correction: it gets called twice only if there is a slot tag in the template.

[AimForNaN]

I thought about a potential alternative of passing this from child to parent (perhaps via provide/inject communication). For composition API it would seem I would need to use the "undocumented" getCurrentInstance function to achieve this, but "outdated" documentation on getCurrentInstance does not recommend using it as an "escape hatch" for this, though I believe my specific use-case is valid and despite getCurrentInstance originally being intended for advanced uses. Nevertheless, I'm not so sure this approach will work where render functions are concerned.