Given that I'm the one maintaining both pieces of code, I don't really see a burden from my angle.

As to exporting libgnomevolumecontrol, I don't really like the idea. The API isn't stable, and the only consumer should be gnome-media itself.

I'd rather gnome-shell made it possible to implement a gnome-shell applet, with mostly C code, and a small js shim. This would be needed to implement an effective Bluetooth applet as well.

For g-s-d: okay, it is your problem, you decide.

For gnome-shell: you need to leverage the extension system for that, and currently there is no API (as opposed to unstable one) that extensions can use to add themselves in the right place.
Also, the design calls for system status indicator that are completely owned and handled by gnome-shell. The developers don't want "core extensions" (extensions implementing core functionality, like in gnome-panel).
Considering previous answers to similar questions (see bug 622451), I believe we need either to copy-paste gvc into gnome-shell, or to use a shared library.

Btw:
- you need introspection anyway. That's the only way to get to JS
- GnomeBluetooth has a public library, and that's all its necessary to implement the indicator (I started it, only to discover gjs segfaults with Gtk.TreeIter...)

Two updates:

1) I succeded in writing the JS part of the volume indicator, using Shell APIs and a quite different look from current g-v-c-applet (more like Ubuntu's SoundMenu). I could not test it because

2) I did not manage to copy paste the g-v-c shared code inside the shell tree. I got a shared library, but introspection won't work unless full PulseAudio is introspected.

I can post patches for what I've done so far if you like.

Gnome Shell now uses its own private PulseAudio binding from bug 629455.