There are situations where content authors have the choice between multiple overlapping microdata vocabularies. For example both schema.org/PostalAddress and vCard are available for marking up postal addresses. Microdata forces content authors to either choose one of them (schema.org because that's what Google supports), or to duplicate their content.

The challenge with supporting multiple vocabularies in microdata is how to associate property names with the vocabularies in absence of vocabulary knowledge. This difficulty has been stated as the reason for rejecting a similar issue here:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13470

The ambiguity can be avoided by generating multiple items from a single itemscope, with one type each. For example:

<div itemscope>
    <span itemprop="streetAddress street-address">26 Dun Aengus</span>,
    <span itemprop="addressLocality locality">Galway</span>,
    <span itemprop="addressCountry country-name">Ireland</span>.
    <meta itemprop="altitem" content="http://schema.org/PostalAddress streetAddress addressLocality addressCountry">
    <meta itemprop="altitem" content="http://microformats.org/profile/hcard street-address locality country-name">
</div>

The altitem property would have to be a microdata built-in property that affects microdata parsing. Its value would be a whitespace-separated list; its effect would be to generate a new alternate item whose itemtype is the first URL from the list. The rest of the list are property names to be copied from the itemscope. The result here would be three items; one untyped item with eight properties; one schema.org typed item with three properties; one vCard typed item with three properties. This proposal is fleshed out here:
http://richard.cyganiak.de/blog/2011/08/multiple-itemtypes-in-microdata/

The point of this example is to argue that support for multiple vocabularies in microdata is possible in a way that is more convenient to authors than forcing them to repeat content.