It looks like a solution to bug 4547 is on the horizon.
https://bugzilla.wikimedia.org/show_bug.cgi?id=4547
See also [Wikitech-l] Reasonably efficient interwiki transclusion http://www.gossamer-threads.com/lists/wiki/wikitech/197322
This will be very useful for templates which Commons has developed, especially language related templates, however I am concerned that people are also planning on using Commons as a repo for Wikipedia infoboxes, and including the *data* on Commons rather than just the template code. e.g.
http://www.mediawiki.org/wiki/User:Peter17/GSoc_2010#Interest
This centralisation of data makes sense on many levels, however using Commons as the host of this data will result in many edit wars moving to the Commons project, involving people from many languages. Even the infobox structure can be the cause of edit wars.
I think it is undesirable to have these Wikipedia problems added to Commons existing problems. ;-)
Tying Wikipedia and Commons closer together is also problematic when we consider the differing audience and scope of each project, especially in light of the recent media problems. If the core templates and data used by Wikipedia are hosted/modified on Commons, it will be more difficult to justify why Commons accepts content which isn't appropriate on Wikipedia.
A centralised data wiki has been proposed previously, many times:
http://meta.wikimedia.org/wiki/Wikidata/historical http://meta.wikimedia.org/wiki/Wikidata http://meta.wikimedia.org/wiki/Wikidata_%282%29 http://meta.wikimedia.org/wiki/WikiDatabank
Non-WMF projects, such as freebase, dbpedia, etc., have been exploring this space.
Isn't it time that we started a new project!? ;-)
A wikidata project could use semantic mediawiki from the outset, and be seeded with data from dbpedia.
A lot of existing & proposed projects would benefit from a centralised wikidata project. e.g. a genealogy wiki could use the relationships stored on the wikidata project. wikisource and commons could use the central data wiki for their Author and Creator details.
-- John Vandenberg