Traditionally, the most common sitelinks between Commons and Wikipedias have been from Commons Categories to Wikipedia Articles. However, Commons Categories may also correspond to Wikipedia Categories, and both may have associated galleries. The most natural solution would be for a Wikidata Q-number to be linked with both the Wikipedia article and the Wikipedia category most closely linked to that thing, as well as the relevant Commons category and Commons gallery (if any).
This is not possible as Wikidata is currently constituted. Instead, at present, each item (Q-number) on Wikidata can only be linked to a single target on each sister project.
As a work-around, Wikidata therefore has a parallel structure of category-like items and article-like items, connected by connector properties.
This has the serious drawback that when a reader clicks to an article, they will not see a Commons category link, only a gallery link (if there is one); and if a reader clicks to a Commons category, they will not see links to articles in multiple languages, only categories (in languages where they exist).
It also means that, since at the moment wiki-pages can only access information from Wikidata items to which they are directly linked, it is not currently possible for a Commons category to draw information from the corresponding article-like Wikidata item. This is known as "arbitrary access", and is not expected to be available before early 2015.
These consequences are both deeply unfortunate. However, so long as each Wikidata item can only link to a single target on each sister project, if the structure is to remain stable, predictable and traversable, it is essential that the category-to-category and article-to-article rule is observed.
Could a WikiBase technically replicate this?
- "multiple links to the same site" a.k.a. "Namespace Awareness"
- Would need WikiData to essentially think there were two different wikis on Commons -- commonswiki and commonswikicats, so then it could think there was still only be a single link to each one.
- The MediaWiki -- WikiData interface would need to be adjusted, so MediaWiki sent the namespace as well as the wiki-id
- Properties P301 and P910 would need to turn into the identity function (if cats & articles both existed) or null (if not)
- Some tweaking might be needed, to let a category specifically ask for category-like features, and an article for article-like ones (eg for sidebar links that were not to Commons).
How else would this compare with Wikidata's current model?
- Less reliance on vulnerable "connector" properties, that currently have to maintained and kept in sync
- Currently difficult to ask how many "article" items really link to Categories on Commons -- + integrity is hard to maintain, since people can simply edit in the links they want
Why did Wikidata reject this model?
- "technical difficulties" (more information needed)
- "The descriptive vocabulary for each type of entity is distinct, i.e. there are different descriptive attributes for countries and category pages." 
- different languages have different notions of category trees -- (i) not consistent; (ii) useful info to try to capture which should not be lost
Wikidata's actual model
What needs to be done next
- Create an item for every Commons category if it doesn't exist yet
- Mark these items as instance of Wikimedia category page (Q4167836)
- Link each category to the relevant topic item using category's main topic (P301) and/or category combines topics (P971)
- For category's main topic (P301), also do the inverse topic's main category (P910)
Roadmap and target dates
- Tues 19 Aug: Arbitrary access enabled on a test basis on wikidata.org. Pages will not auto-purge, so not suitable for general release.
- 26-28 Aug: "In other projects sidebar" to be rolled out to Wikipedia, Wikisource and Wikiquote. mw:Beta_Features/Other_projects_sidebar