Considering I did multiple concessions in this one (including getting rid of the '.xml' to 'feed' action converter for SMF... That one was hard to part with >_<)
That sounds like a plan to me. No-one really worries about feed links when moving from other forum software to/from SMF, I see no reason why we are any different - it's not like we're really an SMF version any more.
Look at it when you have a minute, and tell me if that's okay.
OK, so quick look. Reusing the gallery code makes plenty of sense when pulled under the feed... and I can understand the need also to initialise it in a way the gallery would expect. Though it might mean a gradual overhaul of the gallery code in time, I don't know.
The reorganisation of manage plugins is fine, and the new hook is fine also though personally I might have called it feed_types since that's what it really is. But 'feed' is absolutely fine too.
On the subject of passing variables by reference, yes, technically we should probably update everything to not have & in it. However it is nice to leave them in to indicate what the rest of the code expects will be passed by reference; the problem is that hooks can dictate the rules themselves because the receiver indicates its nature rather than the caller. But if we indicate what should be passed, and how (because that intimates what is safe to change and what isn't) that should be OK too.
I seem to recall the determine_location hook only really being useful for pretty URLs because anything else would naturally just head to index.php through a conventional scheme. I dunno. It doesn't hurt to have it where it is though it does mean that even non-PURLs cases would go there too.
The feed compatibility with SMF was always one of those tricky things, as was the mgallery->media change. I personally don't feel a burning need to retain compatibility but that's just me. While SMF->Wedge is the obvious target for conversion, there will be conversions from other systems too and I don't see why they should be treated as second class citizens by comparison. The playing field should be kept level where possible.
I'm curious, why should $_GET be used explicitly for actions? There is one interesting circumstance, though I can't remember where it would ever be an issue, is that if both $_POST and $_GET were to provide an action, $_REQUEST would contain the $_POST version not the $_GET one.