It seems that a package manager is a reasonable way to manage a growing set of dependencies. Composer seems to me (without knowing too much about it) to be a reasonable package manager.
I've heard the objection expressed that this will require new users of wikibase/etc to "learn composer". Presumably the addition of a composer.json file to the repo won't in itself prevent users from using the released tarballs and ignoring composer altogether, so the only folks who have to work with composer are those developing/admining a mediawiki derivative with hairy dependencies, such that learning composer pays for itself. Correct me if I misunderstand.
Can someone outline (for discussion's sake) the other objections to composer? Otherwise, this discussion does not seem too knotty: someone should submit a patch to "composer-ify" mediawiki/core and the various extensions, the release process should include uploading versions to https://packagist.org/ (optional, since composer can apparently install directly from WMF git), and then people should use it for a while before deciding if something else is needed (which may be just patches to composer). --scott, trying to drain the drama out of this discussion and understand the technical issues.
ps. are patches needed to composer to make this process more lightweight/require less modification to mediawiki/core? I note that mediawiki seems to have support in https://github.com/composer/installersalready.
pps. I think the multiple entry points as a technical issue with the installer? By from my reading, there's no reason why you couldn't write a separate 'mediawiki-composer' shell package that included just stub index.php, api.php, etc files which loaded the appropriate entry point from inside vendor/mediawiki or whatever. So (in my understanding) the changes required to mediawiki/core are minimal. Please correct me if I'm wrong (hopefully with a detailed list of the changes actually required).