Hi Ori,
have you looked at mw.track?
mw.track seems to be about "analytics events"? What mmv.head does is capture a click jQuery event (the user clicking on a thumbnail) and replaying it once all the necessary dependencies have been loaded. I didn't see anything like that when I glanced at mw.track's and mw.trackSubscribe code, but maybe I didn't dig deep enough.
mmv.head solves the specific situation where users click on a thumbnail very early when the DOM starts appearing on the page, while keeping the amount of blocking JS in the head to a minimum. We thought of trying to make it generic but it turns out that we need to do a lot of mediaviewer-specific stuff inside of it, which would need to go into the head anyway.
I have a feeling TimedMediaHandler started putting things in the head for similar reasons, expect they forgot the part where you only really need the early click capture mechanism in the head, not the entire app's code :) When we get to cleaning TMH, we'll certainly look into whether or not we can make that capture-early-clicks-and-replay-them behavior logic common.
After we've launched to pilot sites and things have cooled down I plan on writing a technical retrospective of Media Viewer, to showcase the "cool parts" and assorted tricks we had to come up with. I'll make sure to ask if there's any interest in moving some of those things to core. And as Gergo has mentioned elsewhere, we need to wait a little for these things to stand the test of wide production use before preaching their benefits.
You can also warm up the localStorage module cache by doing something like
I think this has the same bandwidth implication as loading the JS asynchronously in the footer, which is our main concern at the moment, considering how big media viewer's JS/CSS is.